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

Aurelijus Stanislovaitis aurelijus.stanislovaitis at owasp.org
Sun Sep 18 18:53:19 UTC 2016


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?


On Sat, Sep 17, 2016 at 1:39 AM, Brad Causey <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>
> 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
>> 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
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20160918/f6c215b5/attachment.html>

More information about the OWASP-Leaders mailing list