<div dir="ltr"><div><div><div><div>I like this many CSRF tokens on one page idea, but can you explain the randomness aspect? I assume that only one of them is the right one, so on the client side, the selection can't be random (is it)?<br><br></div>The idea of a polymorphic login page is pretty cool ....  Not undefeatable of course, but raises the bar even more.<br><br></div>-Dave<br><br></div>p.s. Also, any thoughts on protecting login APIs (per Ory's comment?)<br><br></div>p.p.s. Could a step in the login defense be to create a work factor that the client has to figure out and submit as part of the password submit step? Imagine they had to run some calculation that would typically take 1 second to compute and submit that result, plus the user's password. That would seem to slow them down too. Essentially a work factor CSRF token.<br><div><br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 21, 2016 at 1:23 PM, Eoin Keary <span dir="ltr"><<a href="mailto:eoin.keary@owasp.org" target="_blank">eoin.keary@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="auto"><div>Hey,</div><div>We've had some clients who have undergone cred stuffing attacks. They want to avoid 2FA, CAPTCHA given the line of business they are in, clients would not use the app...</div><div><br></div><div>so to make it more difficult CSRF tokens are embedded in various parts of the html.</div><div>They are per request and tied to session.</div><div>Pages need to be reloaded before every Auth request which slows the brute force by require extra page loads. Tied to session protects against parallel requests and also slows rate of brute force request.</div><div><br></div><div>The tokens are selected at random from the page so it's not so simple for the attacker to simply script one element value as any of the many tokens could be selected and one false move results in failure/temp IP blocking or whatever countermeasure is required.</div><div>This is all invisible to the legitimate user and only kicks in when tokens are incorrect.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div><br><br>Eoin Keary<div>OWASP Volunteer</div><div>@eoinkeary</div><div><span style="font-size:13pt"><br></span></div><div><br></div></div></font></span><div><div class="h5"><div><br>On 21 Sep 2016, at 01:34, Brad Causey <<a href="mailto:bradcausey@owasp.org" target="_blank">bradcausey@owasp.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Good stuff Michael. <div><br></div><div>Part of what makes this interesting is that these attacks evolve as the defenses evolve. </div><div><br></div><div>When we first started defending against this, we called it "credential reuse" and we were able to defeat it by using two step authentication combined with something similar to CSRF protection(basically just have a server variable ensure that a browser was rendering the first step). At the time, most secure sites included the username and password on the same page, and used a single form submission to evaluate the validity of credentials. Every reuse attempt was scripted using simple python or perl, and came from a single IP address, so it was easy to identify by watching the web server logs closely. </div><div><br></div><div>Things have evolved a bit more, but not much from what I've seen. At this point, we are seeing attempts migrate from one IP to another slowly. For example, 1000 attempts from one IP, then 1000 from another, etc.</div><div><br></div><div>If there are highly sophisticated attacks out there, I haven't seen one. Of course, my experience is anecdotal. What we really need is examples of these attacks using whatever advanced methods they are using. Even if it's just log files. </div><div><br></div><div>Has anyone seen a more evolved version of this? </div><div><br></div><div>By my estimation, MFA plus behavior and device analysis will be the only way to prevent this in it's final stage of evolution.  </div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div data-smartmail="gmail_signature">-Brad Causey<br>CISSP, MCSE, C|EH, CIFI, CGSP<br><br><a href="http://www.owasp.org" target="_blank">http://www.owasp.org</a><br>--<br>"Si vis pacem, para bellum"<br>--</div></div>
<br><div class="gmail_quote">On Tue, Sep 20, 2016 at 6:14 PM, Michael Coates <span dir="ltr"><<a href="mailto:michael.coates@owasp.org" target="_blank">michael.coates@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"><span><div><br>"<span style="font-size:12.8px">For example, lets say that multi-step login caused 90% of the current Credential Stuffing attacks to go away, wouldn't that be worth it?"</span><br></div><div><span style="font-size:12.8px"><br></span></div></span><div>I think we need to be very careful because, without data, we're just speculating on how easy it is to bypass a "basic defense". For consideration a comparable example would be to strip <script> in order to prevent XSS attacks. It may prevent X% of basic XSS attacks, but we all agree it's counterproductive to even suggest this.</div><div><br></div><div>Another example for consideration is multi-submit CSRF attacks. Would we consider a two page form a recommended defense against CSRF attacks? It is slightly more difficult, but not really. </div><div><br></div><div>Lastly, the economics of the attacker market does not require every attacker to recreate the offensive attack wheel. Instead one attacker builds a tool and resells it to many. This is particularly true with credential stuffing attacks see Sentry MBA tool (<a href="http://www.csoonline.com/article/3045247/cyber-attacks-espionage/sentry-mba-makes-credential-stuffing-attacks-easy-and-cheap.html" target="_blank">http://www.csoonline.com/arti<wbr>cle/3045247/cyber-attacks-espi<wbr>onage/sentry-mba-makes-credent<wbr>ial-stuffing-attacks-easy-and-<wbr>cheap.html</a>). At the end the inclusion of an easy to bypass defense would just lead to a false sense of security.</div><div><br></div><div>What to do?</div><div><br></div><div>Recognize this is hard and have a factual discussion that outlines the good defenses (even if they are hard). There are several that are good defenses already included in the cheat sheet. Hopefully the collective focus with a solid understanding of the problem space will lead to additional research and easier defenses.</div><div><br></div><div>Thanks! I'm well aware this is a tough area and excited to see an exploration of the issue.</div></div><div class="gmail_extra"><span><br clear="all"><div><div data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br>--<br>Michael Coates | <a href="https://twitter.com/intent/user?screen_name=_mwc" target="_blank">@_mwc</a><br></div><div>OWASP Global Board<br></div><div dir="ltr"><div><br></div><div><br></div><div><br><br></div></div></div></div></div></div></div></div></div>
<br></span><div><div><div class="gmail_quote">On Tue, Sep 20, 2016 at 10:56 AM, Dave Wichers <span dir="ltr"><<a href="mailto:dave.wichers@owasp.org" target="_blank">dave.wichers@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"><div><div><div>Michael,<br><br></div>I'm not so sure we should drop basic defenses yet, since this problem is so new. I think we should be VERY clear, that we understand certain defenses can be bypassed when they can.<br><br></div>For example, lets say that multi-step login caused 90% of the current Credential Stuffing attacks to go away, wouldn't that be worth it? We all understand this is an arms race, so it will keep getting harder and harder, but I don't think that relatively simple defenses that work today should be discarded. And if that's simply step 1 in your defense, and you plan to add additional layers of defense, then I don't think discarding step 1 is necessary/appropriate.<span><font color="#888888"><br><br></font></span></div><span><font color="#888888">-Dave<br></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 20, 2016 at 1:46 PM, Michael Coates <span dir="ltr"><<a href="mailto:michael.coates@owasp.org" target="_blank">michael.coates@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">Brad,<div><br></div><div>Thanks for kickstarting this cheat sheet. My initial feedback is that we should scrap 3.2 Defense Option 2: Multi-Step Login Process and 3.3 Defense Option 3: IP blacklists. These defenses just don't work against this type of attack. Even if they provide some defense against the most basic attacks I feel it's misleading since it's trivial for an attacker to bypass these defenses and real world attacks show that they regularly do.</div><div><br></div><div>Not meant as a bash on the overall cheat sheet. In fact I think I kicked off this thread and am a big supporter of discussion here. But I think it's good for us to avoid partial solutions that could give a false sense of security.</div><div><br></div><div>I like the other defenses. I think we also can add a few others which are "additional identify verification" and "anti automation.</div></div><div class="gmail_extra"><br clear="all"><div><div data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br>--<br>Michael Coates | <a href="https://twitter.com/intent/user?screen_name=_mwc" target="_blank">@_mwc</a><br></div><div>OWASP Global Board<br></div><div dir="ltr"><div><br></div><div><br></div><div><br><br></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote"><div><div>On Tue, Sep 20, 2016 at 9:39 AM, Brad Causey <span dir="ltr"><<a href="mailto:bradcausey@owasp.org" target="_blank">bradcausey@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">Great discussion so far.<div><br></div><div>Would you folks mind taking a look over this and providing feedback? </div><div><br></div><div>I intend to provide more detail on each subject, but first I figured we could agree on the primary defenses.</div><div><br></div><div><a href="https://www.owasp.org/index.php/Credential_Stuffing_Prevention_Cheat_Sheet" target="_blank">https://www.owasp.org/index.ph<wbr>p/Credential_Stuffing_Preventi<wbr>on_Cheat_Sheet</a><br></div><div><br></div><div><br></div></div>
<br></div></div><span>______________________________<wbr>_________________<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/mailma<wbr>n/listinfo/owasp-leaders</a><br>
<br></span></blockquote></div><br></div>
<br>______________________________<wbr>_________________<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/mailma<wbr>n/listinfo/owasp-leaders</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>______________________________<wbr>_________________</span><br><span>OWASP-Leaders mailing list</span><br><span><a href="mailto:OWASP-Leaders@lists.owasp.org" target="_blank">OWASP-Leaders@lists.owasp.org</a></span><br><span><a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" target="_blank">https://lists.owasp.org/<wbr>mailman/listinfo/owasp-leaders</a></span><br></div></blockquote></div></div></div><br>______________________________<wbr>_________________<br>
OWASP-Leaders mailing list<br>
<a href="mailto:OWASP-Leaders@lists.owasp.org">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/<wbr>mailman/listinfo/owasp-leaders</a><br>
<br></blockquote></div><br></div>