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

Aurelijus Stanislovaitis aurelijus.stanislovaitis at owasp.org
Mon Sep 19 19:21:54 UTC 2016


a difficult battle to win reactively. But the idea of checking leaked pwd
databases against user accounts sounds fresh.
Unfortunately anything more proactive than this would neither be ethical
nor legal, i believe.

br
Aurelijus

On Mon, Sep 19, 2016 at 8:41 PM, Sriram Shyam <sriram.shyam at owasp.org>
wrote:

> But, it couldn't be considered as a brute force as well. Because, once
> someone leaked DB most of the times it comes with email:password format. So
> we just going to see whether it's working or not. How will you block brute
> force attempts.? :/
>
>
> On Monday, September 19, 2016, Rogan Dawes <rogan at dawes.za.net> wrote:
>
>> 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.
>>>
>>>
>
> --
>
> *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/0725c7cf/attachment.html>


More information about the OWASP-Leaders mailing list