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

Rogan Dawes rogan at dawes.za.net
Mon Sep 19 04:17:58 UTC 2016


Agreed!

If it is not available, fall back to brute force protection, but make sure
your accumulations include attacks against multiple users, not just lockout
after 3 wrong passwords for a single account.

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

> But @rogan for that we gotta have that breach data, isn't it? And we could
> not surely say that the breached data could be downloaded easily all the
> times
>
> On Monday, September 19, 2016, Rogan Dawes <rogan at dawes.za.net> wrote:
>
>> 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
>>>
>>
>
> --
>
> *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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20160919/ae4e1277/attachment-0001.html>


More information about the OWASP-Leaders mailing list