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

Sriram Shyam sriram.shyam at owasp.org
Mon Sep 19 17:41:38 UTC 2016


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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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/a585884e/attachment.html>


More information about the OWASP-Leaders mailing list