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

Brad Causey bradcausey at owasp.org
Wed Sep 21 00:34:50 UTC 2016

Good stuff Michael.

Part of what makes this interesting is that these attacks evolve as the
defenses evolve.

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.

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.

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.

Has anyone seen a more evolved version of this?

By my estimation, MFA plus behavior and device analysis will be the only
way to prevent this in it's final stage of evolution.

-Brad Causey

"Si vis pacem, para bellum"

On Tue, Sep 20, 2016 at 6:14 PM, Michael Coates <michael.coates at owasp.org>

> "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?"
> 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.
> 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.
> 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 (http://www.csoonline.com/
> article/3045247/cyber-attacks-espionage/sentry-mba-makes-
> credential-stuffing-attacks-easy-and-cheap.html). At the end the
> inclusion of an easy to bypass defense would just lead to a false sense of
> security.
> What to do?
> 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.
> Thanks! I'm well aware this is a tough area and excited to see an
> exploration of the issue.
> --
> Michael Coates | @_mwc <https://twitter.com/intent/user?screen_name=_mwc>
> OWASP Global Board
> On Tue, Sep 20, 2016 at 10:56 AM, Dave Wichers <dave.wichers at owasp.org>
> wrote:
>> Michael,
>> 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.
>> 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.
>> -Dave
>> On Tue, Sep 20, 2016 at 1:46 PM, Michael Coates <michael.coates at owasp.org
>> > wrote:
>>> Brad,
>>> 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.
>>> 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.
>>> I like the other defenses. I think we also can add a few others which
>>> are "additional identify verification" and "anti automation.
>>> --
>>> Michael Coates | @_mwc
>>> <https://twitter.com/intent/user?screen_name=_mwc>
>>> OWASP Global Board
>>> On Tue, Sep 20, 2016 at 9:39 AM, Brad Causey <bradcausey at owasp.org>
>>> wrote:
>>>> Great discussion so far.
>>>> Would you folks mind taking a look over this and providing feedback?
>>>> I intend to provide more detail on each subject, but first I figured we
>>>> could agree on the primary defenses.
>>>> https://www.owasp.org/index.php/Credential_Stuffing_Preventi
>>>> on_Cheat_Sheet
>>>> _______________________________________________
>>>> 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/20160920/9714c3a9/attachment.html>

More information about the OWASP-Leaders mailing list