dave.wichers at owasp.org
Fri Sep 16 15:08:28 UTC 2016
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-Leaders