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

Rogan Dawes rogan at dawes.za.net
Mon Sep 19 03:33:24 UTC 2016


How about proactively collecting password breach data and testing your
users passwords against it, and forcing a password reset if it matches?

That seems like the best approach to me, and seems to be what the large
sites actually do.

You could also compare at login time and if too many attempts match the
breach data, simply ban the IP, or add captcha solving, etc, as one does
for regular brute force attacks. Obviously, there is a risk of collateral
damage when blacklisting.

Rogan
On Mon, 19 Sep 2016 at 5:01 AM Sriram Shyam <sriram.shyam at owasp.org> wrote:

> Correction : *Dynamic*
>
> On Monday, September 19, 2016, Sriram Shyam <sriram.shyam at owasp.org>
> wrote:
>
>> May be you can try white listing a range of IP's by looking the last
>> three logins. But, most of the devices are using static IP, it's not
>> literally possible in most of the cases.So, we can create a profile page
>> sort of thing in which weshould register our "device".
>> Like a list of devices, for egs: mobile: IMEI, computer: MAC.
>> It's a quite complex thingy but I believe that's the only thing which
>> would help.
>>
>> On Monday, September 19, 2016, Aurelijus Stanislovaitis <
>> aurelijus.stanislovaitis at owasp.org> wrote:
>>
>>> Hi,
>>>
>>> if  we are supposed to prevent mass login attempts then from technical
>>> point of view this not much different than password brute-force attack.
>>>
>>> CSRF is not suitable for this purpose at all, because it does not
>>> prevent automated login. Attacker is free to get the login page along with
>>> all tokens before submitting username+pwd. It may only slow down the rate
>>> of login attempts slightly, if that matters.
>>>
>>> The same can be said about 2 step login process (if still one factor).
>>> Adding steps does not prevent form automated login.
>>>
>>> Device fingerprinting + historical data intrigues and might be a part of
>>> a solution. Details of implementation are the most important. Does it block
>>> login attempts from unseen devices? Or maybe it  does it prevent multiple
>>> logins from the same fingerprint? How fingerprint is calculated, etc.
>>>
>>> I'm not convinced that captha's are useless at all. Yes, bypasses exist,
>>> but is there any research proving that that captcha is fundamentally broken?
>>>
>>> 2FA sounds like an ultimate solution anyway.
>>>
>>> Alternatively might be worthy to look into the root cause of this -
>>> password reusing. How to fix this?
>>>
>>> br
>>> Aurelijus
>>>
>>> On Sat, Sep 17, 2016 at 1:39 AM, Brad Causey <bradcausey at owasp.org>
>>> wrote:
>>>
>>>> Hey Dave!
>>>>
>>>> We've been using basic CSRF protection with a two step login process.
>>>> It basically prevents automated logins.
>>>>
>>>> Of course, that doesn't stop the attacker from manually logging in, or
>>>> scripting a browser.
>>>>
>>>> For that, we use device fingerprinting and historical data.
>>>>
>>>> -Brad
>>>> --
>>>> "Si vis pacem, para bellum"
>>>> --
>>>>
>>>> On Fri, Sep 16, 2016 at 10:08 AM, Dave Wichers <dave.wichers at owasp.org>
>>>> wrote:
>>>>
>>>>> I'm glad to see this article already exists. What I'd love to see next
>>>>> is recommended techniques to defend against this type of attack. I know
>>>>> that such defenses are really hard as this is a complex subject.
>>>>>
>>>>> For example, adding CAPTCHAs just pisses off users and doesn't work
>>>>> anyway.
>>>>>
>>>>> Requiring two factor authentication helps, but makes the site harder
>>>>> to use. And even if you require 2 factor, like the banks do with their
>>>>> username/password (factor 1) then Q/A or saved token (factor 2), they put
>>>>> the normal username/password as step 1, so credential stuffing attacks can
>>>>> still be done, and if there is a match, then the attacker can try to guess
>>>>> the Q/A answer, or spear fish the victim (esp. if the username is their
>>>>> email address, which hopefully its not), etc.
>>>>>
>>>>> Requiring 'real' 2 factor, like sending a pin to the user's mobile
>>>>> phone is far better, but how many sites even provide that as an option,
>>>>> nevermind require it. And I think its even harder for mobile apps as
>>>>> usability for them is even more critical than traditional web apps.
>>>>>
>>>>> Never allowing the username to be the customer's (victim's) email
>>>>> address would help reduce the likelihood of an account name match from one
>>>>> system to another AND help prevent the attacker from spear fishing the
>>>>> victim (because the victim's actually email address wouldn't be obvious).
>>>>> So that's one thing we could recommend.
>>>>>
>>>>> Anyway. This is a complex topic and worthy of discussion. It would be
>>>>> awesome if we could come up with a Credential Stuffing Prevention Cheat
>>>>> Sheet with whatever good ideas we agree would make it harder, and also
>>>>> clearly document the techniques that don't work at all (like use of
>>>>> CAPTCHAs).
>>>>>
>>>>> Has anyone thought really hard about this and wants to discuss? I've
>>>>> only been thinking about it for a couple of days.
>>>>>
>>>>> -Dave
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>
>>
>> --
>>
>> *Regards,Sriram*
>> *Web Application Penetration Tester,*
>>
>> *Director | PrimeFort**OWASP Pondicherry Leader*
>>
>> The information contained in this message and any attachments may be
>> privileged, confidential, proprietary or otherwise protected from
>> disclosure. If you, the reader of this message, are not the intended
>> recipient, you are hereby notified that any dissemination, distribution,
>> copying or use of this message and any attachment is strictly prohibited.
>> If you have received this message in error, please notify the sender
>> immediately by replying to the message, permanently delete it from your
>> computer and destroy any printout.
>>
>>
>
> --
>
> *Regards,Sriram*
> *Web Application Penetration Tester,*
>
> *Director | PrimeFort**OWASP Pondicherry Leader*
>
> The information contained in this message and any attachments may be
> privileged, confidential, proprietary or otherwise protected from
> disclosure. If you, the reader of this message, are not the intended
> recipient, you are hereby notified that any dissemination, distribution,
> copying or use of this message and any attachment is strictly prohibited.
> If you have received this message in error, please notify the sender
> immediately by replying to the message, permanently delete it from your
> computer and destroy any printout.
>
> _______________________________________________
> 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/20160919/27c6029d/attachment-0001.html>


More information about the OWASP-Leaders mailing list