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

Brad Causey bradcausey at owasp.org
Wed Sep 21 01:20:30 UTC 2016


Wow Ryan,

Thanks for that!!! That's certainly a level I've never seen before. Sounds
like you're the SME that needs to help with the cheat sheet! =)

Based on this, do you think that device fingerprinting and MFA are
effective countermeasures?

-Brad Causey
CISSP, MCSE, C|EH, CIFI, CGSP

http://www.owasp.org
--
"Si vis pacem, para bellum"
--

On Tue, Sep 20, 2016 at 7:57 PM, Ryan Barnett <ryan.barnett at owasp.org>
wrote:

> We see account stuffing attacks all the time and they are a huge problem.
> See my blog post here to get an example of the size/scope of attacks -
> https://blogs.akamai.com/2016/06/web-application-defenders-
> field-report-account-takeover-campaigns-spotlight.html
>
>
>
> We are talking millions of participating IP addresses…
>
>
>
> -Ryan
>
>
>
>
>
> *From: *<owasp-leaders-bounces at lists.owasp.org> on behalf of Brad Causey <
> bradcausey at owasp.org>
> *Reply-To: *<bradcausey at owasp.org>
> *Date: *Tuesday, September 20, 2016 at 8:34 PM
> *To: *Michael Coates <michael.coates at owasp.org>
> *Cc: *OWASP Leaders <owasp-leaders at lists.owasp.org>
> *Subject: *Re: [Owasp-leaders] https://www.owasp.org/index.
> php/Credential_stuffing
>
>
>
> 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
> CISSP, MCSE, C|EH, CIFI, CGSP
>
> http://www.owasp.org
> --
> "Si vis pacem, para bellum"
> --
>
>
>
> On Tue, Sep 20, 2016 at 6:14 PM, Michael Coates <michael.coates at owasp.org>
> wrote:
>
>
> "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_Prevention_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
>
>
>
>
>
>
>
> _______________________________________________ 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/c5ff14c4/attachment.html>


More information about the OWASP-Leaders mailing list