How about proactively collecting password breach data and testing your users passwords against it, and forcing a password reset if it matches? <br><br>That seems like the best approach to me, and seems to be what the large sites actually do.<br><br>You could also compare at login time and if too many attempts match the breach data, simply ban the IP, or add captcha solving, etc, as one does for regular brute force attacks. Obviously, there is a risk of collateral damage when blacklisting.<br><br>Rogan<br><div class="gmail_quote"><div dir="ltr">On Mon, 19 Sep 2016 at 5:01 AM Sriram Shyam <<a href="mailto:sriram.shyam@owasp.org">sriram.shyam@owasp.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Correction : *Dynamic*<br><br>On Monday, September 19, 2016, Sriram Shyam <<a href="mailto:sriram.shyam@owasp.org" target="_blank">sriram.shyam@owasp.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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". <div>Like a list of devices, for egs: mobile: IMEI, computer: MAC. </div><div>It's a quite complex thingy but I believe that's the only thing which would help. <br><br>On Monday, September 19, 2016, Aurelijus Stanislovaitis <<a>aurelijus.stanislovaitis@owasp.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi, <div><br></div><div>if  we are supposed to prevent mass login attempts then from technical point of view this not much different than password brute-force attack. </div><div><br><div>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. </div><div><br></div><div>The same can be said about 2 step login process (if still one factor). Adding steps does not prevent form automated login.</div></div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>2FA sounds like an ultimate solution anyway. </div><div><br></div><div>Alternatively might be worthy to look into the root cause of this - password reusing. How to fix this? </div><div><br></div><div>br</div><div>Aurelijus</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 17, 2016 at 1:39 AM, Brad Causey <span dir="ltr"><<a>bradcausey@owasp.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey Dave!<div><br></div><div>We've been using basic CSRF protection with a two step login process. It basically prevents automated logins.</div><div><br></div><div>Of course, that doesn't stop the attacker from manually logging in, or scripting a browser. </div><div><br></div><div>For that, we use device fingerprinting and historical data. </div><div class="gmail_extra"><br clear="all"><div><div data-smartmail="gmail_signature">-Brad <br>--<br>"Si vis pacem, para bellum"<br>--</div></div>
<br><div class="gmail_quote"><div><div>On Fri, Sep 16, 2016 at 10:08 AM, Dave Wichers <span dir="ltr"><<a>dave.wichers@owasp.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><div><div><div>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.<br><br></div>For example, adding CAPTCHAs just pisses off users and doesn't work anyway.<br><br></div>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.<br><br></div><div>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.<br><br>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.<br></div><div><br></div>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).<br></div><div><br></div><div>Has anyone thought really hard about this and wants to discuss? I've only been thinking about it for a couple of days.<span><font color="#888888"><br></font></span></div><span><font color="#888888"><div><br></div>-Dave<br><br></font></span></div>
<br></div></div>_______________________________________________<br>
OWASP-Leaders mailing list<br>
<a>OWASP-Leaders@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" rel="noreferrer" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
<br></blockquote></div><br></div></div>
<br>_______________________________________________<br>
OWASP-Leaders mailing list<br>
<a>OWASP-Leaders@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" rel="noreferrer" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br><br>-- <br><div dir="ltr"><div><div dir="ltr"><div><font color="#000000"><b>Regards,<br>Sriram</b></font></div><div><font color="#000000"><b>Web Application Penetration Tester,</b></font></div><div><font color="#000000"><b>Director | PrimeFort<br></b></font><b>OWASP Pondicherry Leader</b></div><br style="font-size:12.8px"><font size="2" color="#808080"><span style="font-family:"times new roman"">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.</span></font><br></div></div></div><br>
</blockquote><br><br>-- <br><div dir="ltr"><div><div dir="ltr"><div><font color="#000000"><b>Regards,<br>Sriram</b></font></div><div><font color="#000000"><b>Web Application Penetration Tester,</b></font></div><div><font color="#000000"><b>Director | PrimeFort<br></b></font><b>OWASP Pondicherry Leader</b></div><br style="font-size:12.8px"><font size="2" color="#808080"><span style="font-family:"times new roman"">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.</span></font><br></div></div></div><br>
_______________________________________________<br>
OWASP-Leaders mailing list<br>
<a href="mailto:OWASP-Leaders@lists.owasp.org" target="_blank">OWASP-Leaders@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" rel="noreferrer" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
</blockquote></div>