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

Brad Causey bradcausey at owasp.org
Tue Sep 20 12:42:15 UTC 2016


A couple of follow up points.

Most every one of these ideas could easily be augmented by associating
common user or device behavior variables.

For example, in Rogan's login monitoring with IP tracking, it would be
easily to eliminate (most) false positives if the last three IPs that the
user's account logged in from were tracked and compared to the suspected
"bad" IP.

Further, making the IP bans temporary, say 15 minutes, we would reduce the
negative impact to the customer and business services (who would have to
fix false positives) significantly.

Also, by running some simple javascript device information collections, we
can learn certain things about the device(s) used to log into each account.
If a Windows/Engish/Chrome device logged in the last 5 times, and we now
have a new geo location source with Linux/FireFox/Spanish, then we can be
pretty certain that the user is not the real one. (other options include
timezones, last login times, user agents, etc)

As with any approach, no single one will be perfect, but layering 2 or 3
approaches will stop the vast majority of attempts.

Also, as a side note, remember that the folks who are trying to verify
accounts using this method are not going to take great pains to avoid
detection (such as with proxies, and dozens of bots, etc) because the
return on investment is poor in doing so.


-Brad Causey
CISSP, MCSE, C|EH, CIFI, CGSP

http://www.owasp.org
--
"Si vis pacem, para bellum"
--

On Tue, Sep 20, 2016 at 1:58 AM, Aurelijus Stanislovaitis <
aurelijus.stanislovaitis at owasp.org> wrote:

> In case of 'stuffing'  the expected failed login rate is much lower
> compared to any bruteforce, i assume.
> It does not make much sense in counting failed logins per user, because an
> attacker would only attempt 1 password per user. The increased cumulative
> amount of logins per time period could be an indication, but then we can
> not lockout accounts of course.
>
> The attacker switching proxies for different requests or utilizing
> anything distributed such as botnet would  not increase the counter per IP
> address significantly either.
> For above reason the benefit of banning IP addresses can also be doubtful.
> It is important to avoid banning legitimate users. Banning IP address after
> several failed login attempts could  deny access to the large corporate
> network sitting behind NAT in case of false positive. Tarpit sounds better
> however.
>
> But these are  only my theoretical thoughts.  I would really be happy to
> find out more about real implementations even if they are not perfect.
>
> br
> Aurelijus
>
> On Tue, Sep 20, 2016 at 6:42 AM, Rogan Dawes <rogan at dawes.za.net> wrote:
>
>> From a detection perspective, how is an attacker doing a horizontal brute
>> force attack (most commonly defined as checking all users for a single
>> common password) different from an attacker checking a list of users and
>> passwords?
>>
>> I can't see any difference myself.
>>
>> You monitor login attempts, increment failed logins per user, increment
>> failed logins per ip address, and lock out or ban (or tar pit) once
>> thresholds are exceeded.
>>
>> Rogan
>>
>
>
> _______________________________________________
> 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/20160920/389e41e3/attachment.html>


More information about the OWASP-Leaders mailing list