Slow Down Online Guessing Attacks with Device Cookies - Revision history

Adedov: Clarify algorithm

2017-12-06T07:30:33Z

Clarify algorithm

Adedov at 07:01, 23 August 2016

2016-08-23T07:01:09Z

Adedov: Implementation Tips

2016-08-23T07:00:39Z

Implementation Tips

Adedov: Change one threat status to "mitigated".

2016-08-22T22:07:36Z

Change one threat status to "mitigated".

Jmanico at 10:05, 29 June 2016

2016-06-29T10:05:29Z

Adedov: Change links to video.

2015-02-26T09:37:11Z

Change links to video.

Adedov: Categorisation

2015-02-25T10:14:59Z

Categorisation

Adedov: /* Intro */

2015-02-25T09:16:57Z

‎Intro

Adedov: Initial version of article.

2015-02-24T21:50:34Z

Initial version of article.

New page

==Intro==
This is ''by no means'' my idea. I’ve overheard the term “device cookie” from Marc Heuse at PasswordsCon 14, also Alec Muffett mentioned “datr” cookie from Facebook in his talk at the same conference. So, the only purpose for this writing is to put the idea into ready-to-implement condition and to raise public discussion about its security or may be insecurity and scarce usefulness.

The main idea behind the protocol is to issue a special “device” cookie to every client (browser) when it is used to successfully authenticate a user in a system. The device cookie can be used to:
* Distinguish between known/trusted and unknown/untrusted clients
* Establish universal temporary lockouts for all untrusted clients
* Lockout trusted clients individually.

==Why?==
There are few well-known ways to [[Blocking_Brute_Force_Attacks|deal with online attacks]]:
* Temporary account lockout
* Use CAPTCHA to slow down attacker

Other tricks, like producing confusing answers for attacker are more like “security by obscurity” and cannot be used as first-class protection mechanism.

Temporary account lockout after several failed attempts is too simple of a target for DoS attacks against legitimate users. There is variation of this method that locks out pair of account/IP. It is better in regarding to DoS issues but have security downsides:
* Attacks from botnets can be effective
* Attacks through proxies can be effective

Moreover, it is not so trivial to implement account/IP lockout. Consider multiple proxies with chaining addresses in “X-Forwarded-For” header or IPv6.

The method described in this writing may be viewed as variant of account/IP blocking. But it proposes to use a browser cookie instead of an IP address. Thus it may be more predictable from security perspective and easier to implement.

==Protocol==
Protocol parameters:
* T - time period
* N - max number of authentication attempts allowed during ''T''

The sign ∎ hereafter states for end of algorithm.

'''Entry point for authentication request'''
# if the incoming request contains a device cookie:
#: a. ''validate device cookie''
#: b. if the device cookie is valid and not in the lockout list
#:: ''authenticate user''∎
# if authentication from untrusted clients is locked out for the specific user
#: reject authentication attempt∎
# else
#: ''authenticate user''∎

'''Authenticate user'''
# check user credentials
# if credentials are valid
#: a. ''issue new device cookie to user’s client''
#: b. proceed with authenticated user
# else
#: a. ''register failed authentication attempt''
#: b. finish with failed user’s authentication

'''Register failed authentication attempt'''
# register a failed authentication attempt with following information: { user, time, device cookie (if present) }.
# depending on whether a valid device cookie is present in the request, count the number of failed authentication attempts within period ''T'' either for
#: a. all untrusted clients
#: '''or'''
#: b. a specific device cookie
# if number of failed attempts within period ''T'' > ''N''
#: a. if a valid device cookie is presented
#:: put the device cookie into the lockout list for device cookies until now+''T''
#: b. else
#:: lockout all authentication attempts for a specific user from all untrusted clients until now+''T''

'''Issue new device cookie to user’s client'''
Issue a browser cookie with a value like “LOGIN,NONCE,SIGNATURE”, where
* LOGIN - user’s login name (or internal ID) corresponding to an authenticated user
* NONCE - nonce of sufficient length or random value from CSRNG source
* SIGNATURE - HMAC(secret-key, “LOGIN,NONCE”)
* secret-key - server’s secret cryptographic key.

'''Validate device cookie'''
# Validate that the device cookie is formatted as described above
# Validate that SIGNATURE == HMAC(secret-key, “LOGIN,NONCE”)
# Validate that LOGIN represents the user who is actually trying to authenticate

===Notes===
* Putting the device cookie in a lockout list has the same effect as if the client had no device cookie. So clients with device cookies are potentially allowed to make ''N'' * 2 failed authentication attempts before actual lockout.
* Issuing a new device cookie after each successful authentication allows us to avoid making decisions in situations like - “Should the system block a device cookie if there were registered ''N''-1 failed attempts, then one successful authentication, and then again 1 failed attempt? All within period ''T''.”

==Threat Analysis==
{| class="wikitable"
|-
! style="width:20%" | Threat
! style="width:40%" | Threat details
! style="width:40%" | Mitigation
|-
| Online attack against one user
| Attacker performs a guessing attack against a specific account from an untrusted client(s).
| As long as the lockout for untrusted clients blocks authN attempts for a specific user from all untrusted clients, the number of guesses is restricted with (''N/T'')*24h per day.

E.g. for ''N'' = 10 and ''T'' = 1h, any attacker will be limited with 240 attempts per day per user or 87600 attempts per user/year regardless of how large the botnet in his possession is.

If there is a [http://password-policy-testing.wikidot.com/results#toc5 good password policy] in place that limits minimum number attempts to [http://research.microsoft.com/pubs/227130/WhatsaSysadminToDo.pdf 10<sup>6</sup>] then the targeted attack will last (on average) 5 years.
|-
| Online attack using stolen device cookies
| Attacker performs long-running guessing attack against specific account(s) from known clients.

Using valid device cookies allows the attacker to scale attacks linearly, e.g. each device cookie adds extra ''N'' attempts per ''T'' for specific user.
| There may be two ways to steal device cookies:
* Using physical access to a known client
* Active attack against a remote client

In both cases if the attacker can steal device cookies on a regular basis he may have enough power to steal not only device cookies but also session cookies or even passwords. However in our security model this attack is irrelevant if device cookies are adequately protected (use '''Secure''' and '''HttpOnly''' flags).

'''Proposal''': Accidental access to one device cookie contributes little to attack speed. Applications may implement persistent lockout for certain device cookies to address such cases. E.g. permanently lockout a device cookie after ''N''*10 failed attempts.
|- style="background-color:#f5e68d;"
| Online attack against multiple users
| Attacker performs guessing attack against a specific number of accounts from untrusted clients.

Attacker may try the same password from a long list against many (all) accounts in a system without reaching ''N'' failed attempts per account during period ''T''.
| There is no specific mitigation for this threat in the protocol.

Good password policy may be a sufficient countermeasure for such attacks.

Additionally an application may temporarily require CAPTCHA solving for authentication from '''untrusted''' clients in case there are too many authentication attempts for different accounts during a specified period of time.
|-
| Spoof device cookie
| Attacker may try to forge a valid device cookie for any user in a system.
| Proper crypto implementation: HMAC and random secret key.
|-
| Tamper with existing device cookie
| Attacker may try to tamper with a device cookie valid for one user to make it suitable for another.
| Proper crypto implementation: HMAC and random secret key.
|- style="background-color:#f5e68d;"
| DoS for specific account
| Attackers may cause permanent lockout for all untrusted devices for a specific user. Thus the user may be blocked from loggging into the system as he would need to login from a '''new device''' or to login after '''cleaning up his browser cache'''.
| No mitigation yet.

'''Proposal:''' Issue a valid device cookie after visiting password reset link (an actual password reset would not be necessary). Thus, if the user demonstrates his possession of a personal email account then the system may trust his client to enter credentials.
|-
| DoS for specific account when client is used by different accounts
| There are situations when the same client is legitimately used to authenticate different users. For example, a family-shared PC or tablet. Thus, after successful authentication of one user another legitimate user will be treated as user of untrusted client and will be susceptible to a DoS attack.
| Cases where the same client is shared between legitimate users may be considered out of scope by default.

If such cases are critical for application usability, it may deal with them by issuing device cookies with names that contain LOGIN and analyze them accordingly.
|}

@@ Line 1: / Line 1: @@
 [[Category:Control]][[Category:Authentication]]
 ==Intro==
-Device cookies as additional authenticator for users devices have been discussed and used in practice for some time already. For example, it was discussed by Marc Heuse at [http://new.livestream.com/NTNU/passwords14 PasswordsCon 14]. Marc speculates on various techniques for blocking online attacks and comes to notion of "device cookie" as good protection alternative (see his talk on Hydra at PasswordsCon 14 [http://new.livestream.com/NTNU/passwords14/videos/70678187 day 1], specifically from 00:43:00). As well as Alec Muffett at the same conference mentions "datr cookie" from Facebook (look from 4:22:00 at PasswordCon 14 [http://new.livestream.com/NTNU/passwords14/videos/70751388 day 3]).
+Device cookies as additional authenticator for users devices have been discussed and used in practice for some time already. For example, it was discussed by Marc Heuse at [http://video.adm.ntnu.no/serier/5493ea75d5589 PasswordsCon 14]. Marc speculates on various techniques for blocking online attacks and comes to notion of "device cookie" as good protection alternative (see his [http://video.adm.ntnu.no/pres/549401c165887 talk] on Hydra at PasswordsCon 14, specifically from 32:50). As well as Alec Muffett at the same conference mentions "datr cookie" from Facebook (look from 10:15 of his [http://video.adm.ntnu.no/pres/54b660049af94 talk]).
 The main idea behind the protocol is to issue a special “device” cookie to every client (browser) when it is used to successfully authenticate a user in a system. The device cookie can be used to:

← Older revision		Revision as of 10:14, 25 February 2015
Line 1:		Line 1:
		+	[[Category:Control]][[Category:Authentication]]
	==Intro==		==Intro==
	Device cookies as additional authenticator for users devices have been discussed and used in practice for some time already. For example, it was discussed by Marc Heuse at [http://new.livestream.com/NTNU/passwords14 PasswordsCon 14]. Marc speculates on various techniques for blocking online attacks and comes to notion of "device cookie" as good protection alternative (see his talk on Hydra at PasswordsCon 14 [http://new.livestream.com/NTNU/passwords14/videos/70678187 day 1], specifically from 00:43:00). As well as Alec Muffett at the same conference mentions "datr cookie" from Facebook (look from 4:22:00 at PasswordCon 14 [http://new.livestream.com/NTNU/passwords14/videos/70751388 day 3]).		Device cookies as additional authenticator for users devices have been discussed and used in practice for some time already. For example, it was discussed by Marc Heuse at [http://new.livestream.com/NTNU/passwords14 PasswordsCon 14]. Marc speculates on various techniques for blocking online attacks and comes to notion of "device cookie" as good protection alternative (see his talk on Hydra at PasswordsCon 14 [http://new.livestream.com/NTNU/passwords14/videos/70678187 day 1], specifically from 00:43:00). As well as Alec Muffett at the same conference mentions "datr cookie" from Facebook (look from 4:22:00 at PasswordCon 14 [http://new.livestream.com/NTNU/passwords14/videos/70751388 day 3]).

@@ Line 33: / Line 33: @@
 '''Entry point for authentication request'''
-# if the incoming request contains a device cookie:
-#: a. ''validate device cookie''
+:1. if the incoming request contains a device cookie:
-#: b. if the device cookie is valid and not in the lockout list
+:: a. ''validate device cookie''
-#:: ''authenticate user''∎
+:: b. if device cookie is not valid then proceed to step 2.
-# if authentication from untrusted clients is locked out for the specific user
+:: c. if the device cookie is in the lockout list
-#: reject authentication attempt∎
+::: reject authentication attempt∎
-# else
+:: d. else
-#: ''authenticate user''∎
+::: ''authenticate user''∎
 '''Authenticate user'''

@@ Line 6: / Line 6: @@
 * Establish universal temporary lockouts for all untrusted clients
 * Lockout trusted clients individually.
 =Why?=
@@ Line 21: / Line 22: @@
 The method described in this writing may be viewed as variant of account/IP blocking. But it proposes to use a browser cookie instead of an IP address. Thus it may be more predictable from security perspective and easier to implement.
 =Protocol=

@@ Line 76: / Line 76: @@
 * Putting the device cookie in a lockout list has the same effect as if the client had no device cookie. So clients with device cookies are potentially allowed to make ''N'' * 2 failed authentication attempts before actual lockout.
 * Issuing a new device cookie after each successful authentication allows us to avoid making decisions in situations like - “Should the system block a device cookie if there were registered ''N''-1 failed attempts, then one successful authentication, and then again 1 failed attempt? All within period ''T''.”
 =Threat Analysis=

@@ Line 121: / Line 121: @@
 | Attacker may try to tamper with a device cookie valid for one user to make it suitable for another.
 | Proper crypto implementation: HMAC and random secret key.
-|- style="background-color:#f5e68d;"
+|-
 | DoS for specific account
 | Attackers may cause permanent lockout for all untrusted devices for a specific user. Thus the user may be blocked from loggging into the system as he would need to login from a '''new device''' or to login after '''cleaning up his browser cache'''.
-| No mitigation yet.
+Issue a valid device cookie after visiting password reset link (an actual password reset is not necessary). Thus, if the user demonstrates his possession of a personal email account then the system may trust a client to try entering his credentials.
 |-
 | DoS for specific account when client is used by different accounts

@@ Line 1: / Line 1: @@
-[[Category:Control]][[Category:Authentication]]
+=Intro=
 Device cookies as additional authenticator for users devices have been discussed and used in practice for some time already. For example, it was discussed by Marc Heuse at [http://video.adm.ntnu.no/serier/5493ea75d5589 PasswordsCon 14]. Marc speculates on various techniques for blocking online attacks and comes to notion of "device cookie" as good protection alternative (see his [http://video.adm.ntnu.no/pres/549401c165887 talk] on Hydra at PasswordsCon 14, specifically from 32:50). As well as Alec Muffett at the same conference mentions "datr cookie" from Facebook (look from 10:15 of his [http://video.adm.ntnu.no/pres/54b660049af94 talk]).
@@ Line 8: / Line 7: @@
 * Lockout trusted clients individually.
-==Why?==
+=Why?=
 There are few well-known ways to [[Blocking_Brute_Force_Attacks|deal with online attacks]]:
 * Temporary account lockout
@@ Line 23: / Line 22: @@
 The method described in this writing may be viewed as variant of account/IP blocking. But it proposes to use a browser cookie instead of an IP address. Thus it may be more predictable from security perspective and easier to implement.
-==Protocol==
+=Protocol=
 Protocol parameters:
 * T - time period
@@ Line 74: / Line 73: @@
 # Validate that LOGIN represents the user who is actually trying to authenticate
-===Notes===
+==Notes==
 * Putting the device cookie in a lockout list has the same effect as if the client had no device cookie. So clients with device cookies are potentially allowed to make ''N'' * 2 failed authentication attempts before actual lockout.
 * Issuing a new device cookie after each successful authentication allows us to avoid making decisions in situations like - “Should the system block a device cookie if there were registered ''N''-1 failed attempts, then one successful authentication, and then again 1 failed attempt? All within period ''T''.”
-==Threat Analysis==
+=Threat Analysis=
 {| class="wikitable"
 |-