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

Brad Causey bradcausey at owasp.org
Tue Sep 20 18:13:54 UTC 2016


I agree that it should be more clear.

I was trying to get deep enough to be clear, while not going so far as to
write a thesis on device fingerprinting, although that might be needed here.

Fingerprinting variables are weighted on a scale that includes both
likelihood of change and impact of change.

For example, browser version changes monthly in many cases, as new versions
are released for various reasons. This would have a high likelihood of
change, and low impact of change. The low impact is because a legitimate
device is probably going to have their browser version change periodically.
(although it should only change forward in most cases)

In a different example, a variable such as Language should never change,
even if the access comes from another device. Language would be a low
likelihood and high impact. High impact because devices don't generally
change languages.

The reason I say the following:

If you are performing complex device fingerprinting, using many variables,
> then more severe actions might be taken, such as locking the account.


Is because you can be more certain that the device is a different one. By
complex, I mean that many variables are being used. If I know that several
things changed, and by weight, I find that 80% of the device variables are
different, then it's going to tell me that it's not the same device.

By comparison:

 Using simple fingerprinting, with maybe 2 or 3 variables would require
> that less stringent actions be taken, due to it's higher likelihood of a
> false positive. In this case, maybe the source IP is blocked if it attempts
> more than 3 user IDs.


With only 3 variables, a single variable change would be a 33% change. Only
two variables changing would be a majority. If these variables are browser
version and IP address, then your reliability in being sure that the device
is not the same is very poor.

Hopefully that makes sense.

Thanks for the feedback!




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

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

On Tue, Sep 20, 2016 at 1:02 PM, Rogan Dawes <rogan at dawes.za.net> wrote:

> How you deal with mismatches is also a major consideration.
>
> 1. If you are performing complex device fingerprinting, using many
> variables, then more severe actions might be taken, such as locking the
> account.
>
> 2. Using simple fingerprinting, with maybe 2 or 3 variables would require
> that less stringent actions be taken, due to it's higher likelihood of a
> false positive. In this case, maybe the source IP is blocked if it attempts
> more than 3 user IDs.
>
> I think you may have this backwards, or alternatively, there are multiple
> interpretations. At the very least, i think it needs to be clarified
> substantially.
>
> For example, 1. is missing under what circumstances action should be
> taken. When the match fails, or succeeds? What sort of data points are to
> be compared or recorded?
>
> It seems to me that the more data points you compare on, the more likely
> you are to get false positives. For example, the user upgrades their
> browser, and the ua string changes accordingly, do we lock their account?
>
>
> Rogan
>
> On Tue, 20 Sep 2016 at 6:39 PM Brad Causey <bradcausey at owasp.org> wrote:
>
>> Great discussion so far.
>>
>> Would you folks mind taking a look over this and providing feedback?
>>
>> I intend to provide more detail on each subject, but first I figured we
>> could agree on the primary defenses.
>>
>> https://www.owasp.org/index.php/Credential_Stuffing_
>> Prevention_Cheat_Sheet
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20160920/81a77871/attachment.html>


More information about the OWASP-Leaders mailing list