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

Dave Wichers dave.wichers at owasp.org
Thu Sep 22 00:25:43 UTC 2016


Regarding protecting APIs, Google many years ago used to require people to
preregister to gain access to their public search APIs, and Google then
issued them what was effectively a long term session token. That allowed
Google to track customer behavior when using those APIs and shut off access
if they saw abuse.

Would something like this work? What are the pros/cons you can think of?
The request for these API tokens would have to have anti-automation
defenses as well. Imagine they put in place a 2 minute hashcash cost to get
one. And then they emailed the token to you (and it had to be a different
email each time or you couldn't request one again with that email for a
week). This would make it harder to gather lots of these tokens.

-Dave


On Wed, Sep 21, 2016 at 4:58 PM, Ryan Barnett <ryan.barnett at owasp.org>
wrote:

> Dave,
> Regarding your pps - funny you should mention that as I was just
> discussing the hashcash concept with Ory.  Again - this helps to raise the
> cost of attacking normal login pages where the client must execute
> JavaScript but doesn't help vs APIs.
>
> *Ryan Barnett*
>
>
>
> On Sep 21, 2016, at 4:39 PM, Dave Wichers <dave.wichers at owasp.org> wrote:
>
> 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)?
>
> The idea of a polymorphic login page is pretty cool ....  Not undefeatable
> of course, but raises the bar even more.
>
> -Dave
>
> p.s. Also, any thoughts on protecting login APIs (per Ory's comment?)
>
> 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.
>
>
>
> On Wed, Sep 21, 2016 at 1:23 PM, Eoin Keary <eoin.keary at owasp.org> wrote:
>
>> Hey,
>> 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...
>>
>> so to make it more difficult CSRF tokens are embedded in various parts of
>> the html.
>> They are per request and tied to session.
>> 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.
>>
>> 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.
>> This is all invisible to the legitimate user and only kicks in when
>> tokens are incorrect.
>>
>>
>>
>> Eoin Keary
>> OWASP Volunteer
>> @eoinkeary
>>
>>
>>
>> On 21 Sep 2016, at 01:34, Brad Causey <bradcausey at owasp.org> wrote:
>>
>> 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-espi
>>> onage/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
>>>>>
>>>>>
>>>>
>>>
>> _______________________________________________
>> 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/20160921/aa3aa34d/attachment-0001.html>


More information about the OWASP-Leaders mailing list