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

Rogan Dawes rogan at dawes.za.net
Thu Sep 22 03:03:57 UTC 2016


Unfortunately, email addresses are not scarce resources.
On Thu, 22 Sep 2016 at 2:25 AM Dave Wichers <dave.wichers at owasp.org> wrote:

> 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-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
>>>
>>>
>>> _______________________________________________
>>> 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/20160922/6aa66cb2/attachment-0001.html>


More information about the OWASP-Leaders mailing list