[Owasp-leaders] https://www.owasp.org/index.php/Credential_stuffing

Sriram Shyam sriram.shyam at owasp.org
Mon Sep 19 02:59:44 UTC 2016

May be you can try white listing a range of IP's by looking the last three
logins. But, most of the devices are using static IP, it's not literally
possible in most of the cases.So, we can create a profile page sort of
thing in which weshould register our "device".
Like a list of devices, for egs: mobile: IMEI, computer: MAC.
It's a quite complex thingy but I believe that's the only thing which would

On Monday, September 19, 2016, Aurelijus Stanislovaitis <
aurelijus.stanislovaitis at owasp.org> wrote:

> Hi,
> if  we are supposed to prevent mass login attempts then from technical
> point of view this not much different than password brute-force attack.
> CSRF is not suitable for this purpose at all, because it does not prevent
> automated login. Attacker is free to get the login page along with all
> tokens before submitting username+pwd. It may only slow down the rate of
> login attempts slightly, if that matters.
> The same can be said about 2 step login process (if still one factor).
> Adding steps does not prevent form automated login.
> Device fingerprinting + historical data intrigues and might be a part of a
> solution. Details of implementation are the most important. Does it block
> login attempts from unseen devices? Or maybe it  does it prevent multiple
> logins from the same fingerprint? How fingerprint is calculated, etc.
> I'm not convinced that captha's are useless at all. Yes, bypasses exist,
> but is there any research proving that that captcha is fundamentally broken?
> 2FA sounds like an ultimate solution anyway.
> Alternatively might be worthy to look into the root cause of this -
> password reusing. How to fix this?
> br
> Aurelijus
> On Sat, Sep 17, 2016 at 1:39 AM, Brad Causey <bradcausey at owasp.org
> <javascript:_e(%7B%7D,'cvml','bradcausey at owasp.org');>> wrote:
>> Hey Dave!
>> We've been using basic CSRF protection with a two step login process. It
>> basically prevents automated logins.
>> Of course, that doesn't stop the attacker from manually logging in, or
>> scripting a browser.
>> For that, we use device fingerprinting and historical data.
>> -Brad
>> --
>> "Si vis pacem, para bellum"
>> --
>> On Fri, Sep 16, 2016 at 10:08 AM, Dave Wichers <dave.wichers at owasp.org
>> <javascript:_e(%7B%7D,'cvml','dave.wichers at owasp.org');>> wrote:
>>> I'm glad to see this article already exists. What I'd love to see next
>>> is recommended techniques to defend against this type of attack. I know
>>> that such defenses are really hard as this is a complex subject.
>>> For example, adding CAPTCHAs just pisses off users and doesn't work
>>> anyway.
>>> Requiring two factor authentication helps, but makes the site harder to
>>> use. And even if you require 2 factor, like the banks do with their
>>> username/password (factor 1) then Q/A or saved token (factor 2), they put
>>> the normal username/password as step 1, so credential stuffing attacks can
>>> still be done, and if there is a match, then the attacker can try to guess
>>> the Q/A answer, or spear fish the victim (esp. if the username is their
>>> email address, which hopefully its not), etc.
>>> Requiring 'real' 2 factor, like sending a pin to the user's mobile phone
>>> is far better, but how many sites even provide that as an option, nevermind
>>> require it. And I think its even harder for mobile apps as usability for
>>> them is even more critical than traditional web apps.
>>> Never allowing the username to be the customer's (victim's) email
>>> address would help reduce the likelihood of an account name match from one
>>> system to another AND help prevent the attacker from spear fishing the
>>> victim (because the victim's actually email address wouldn't be obvious).
>>> So that's one thing we could recommend.
>>> Anyway. This is a complex topic and worthy of discussion. It would be
>>> awesome if we could come up with a Credential Stuffing Prevention Cheat
>>> Sheet with whatever good ideas we agree would make it harder, and also
>>> clearly document the techniques that don't work at all (like use of
>>> CAPTCHAs).
>>> Has anyone thought really hard about this and wants to discuss? I've
>>> only been thinking about it for a couple of days.
>>> -Dave
>>> _______________________________________________
>>> OWASP-Leaders mailing list
>>> OWASP-Leaders at lists.owasp.org
>>> <javascript:_e(%7B%7D,'cvml','OWASP-Leaders at lists.owasp.org');>
>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> <javascript:_e(%7B%7D,'cvml','OWASP-Leaders at lists.owasp.org');>
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders


*Web Application Penetration Tester,*

*Director | PrimeFort**OWASP Pondicherry Leader*

The information contained in this message and any attachments may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If you, the reader of this message, are not the intended
recipient, you are hereby notified that any dissemination, distribution,
copying or use of this message and any attachment is strictly prohibited.
If you have received this message in error, please notify the sender
immediately by replying to the message, permanently delete it from your
computer and destroy any printout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20160919/88bf210a/attachment-0001.html>

More information about the OWASP-Leaders mailing list