OWASP - User contributions [en]

Slow Down Online Guessing Attacks with Device Cookies

2017-12-06T07:30:33Z

Adedov: Clarify algorithm

=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]).

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'''

:1. if the incoming request contains a device cookie:
:: a. ''validate device cookie''
:: b. if device cookie is not valid then proceed to step 2.
:: c. if the device cookie is in the lockout list
::: reject authentication attempt∎
:: d. else
::: ''authenticate user''∎
:2. if authentication from untrusted clients is locked out for the specific user
:: reject authentication attempt∎
:3. 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''.”

=Implementation Tips=
It is good idea to use standard format for device cookies. So, if the size of a cookie is not an issue, it is recommended to use [https://jwt.io/ JWT].

The following standard [https://tools.ietf.org/html/rfc7519#page-9 claims] can be used:
* '''sub''' : LOGIN
* '''jti''' : NONCE

'''Important''': If you already use JWT for storing session tokens or other security stuff make sure you cannot confuse device cookies with other types of tokens. There are two possible ways to mitigate this threat:
# Use different signature / encryption keys for different token types
# Add '''aud''' claim into device cookie token that unambiguously refers to brute force protection subsystem (e.g. "aud" : "brute-force-protection" or "device cookie").

=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 106] 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.
|-
| 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'''.
|
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
| 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.
|}

Talk:JSON Web Token (JWT) Cheat Sheet for Java

2017-05-27T21:53:23Z

Adedov: Question on document scope

Hi!

In fact, his project needs more specific scoping:
* Do you want create lib to facilitate using JWT instead of UI sessions in a secure way? [see http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/]
* Do you want to provide framework that protects developers from common JWT failures?
* Do you want do that on top of existing libraries?
* Why you want to limit this project to Java?

--[[User:Adedov|Adedov]] ([[User talk:Adedov|talk]]) 16:53, 27 May 2017 (CDT)

Slow Down Online Guessing Attacks with Device Cookies

2016-08-23T07:01:09Z

Adedov:

=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]).

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''.”

=Implementation Tips=
It is good idea to use standard format for device cookies. So, if the size of a cookie is not an issue, it is recommended to use [https://jwt.io/ JWT].

The following standard [https://tools.ietf.org/html/rfc7519#page-9 claims] can be used:
* '''sub''' : LOGIN
* '''jti''' : NONCE

'''Important''': If you already use JWT for storing session tokens or other security stuff make sure you cannot confuse device cookies with other types of tokens. There are two possible ways to mitigate this threat:
# Use different signature / encryption keys for different token types
# Add '''aud''' claim into device cookie token that unambiguously refers to brute force protection subsystem (e.g. "aud" : "brute-force-protection" or "device cookie").

=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 106] 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.
|-
| 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'''.
|
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
| 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.
|}

Slow Down Online Guessing Attacks with Device Cookies

2016-08-23T07:00:39Z

Adedov: Implementation Tips

=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]).

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''.”

=Implementation Tips=
It is good idea to use standard format for device cookies. So, if the size of a cookie is not an issue, it is recommended to use [https://jwt.io/ JWT].

The following standard [https://tools.ietf.org/html/rfc7519#page-9 claims] can be used:
* '''sub''' : LOGIN
* '''jti''' : NONCE

'''Important''': If you already use JWT for storing session tokens or other security stuff make sure you cannot confuse device cookies with other types of tokens. There are two possible ways to mitigate this threat:
# Use different signature / encryption keys for different token types
# Add '''aud''' claim into device cookie token that unambiguously refers to brute force protection subsystem (e.g. "aud" : "brute-force-protection" or "device cookie").

=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 106] 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.
|-
| 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'''.
|
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
| 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.
|}

Slow Down Online Guessing Attacks with Device Cookies

2016-08-22T22:07:36Z

Adedov: Change one threat status to "mitigated".

=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]).

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 106] 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.
|-
| 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'''.
|
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
| 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.
|}

Password policy (Draft)

2015-11-20T23:27:06Z

Adedov: Add links section

'''This document is an attempt to write draft replacement for [[Password length & complexity]] page.'''

==What Is Password Policy==
TODO

==Threat Model==
There are three main threats against to user passwords:
* Online attacks
* Offline attacks
* Password leaks

===Online Attacks===
In this mode attacker tries to guess users passwords by sending candidate passwords directly to attacking service.

The speed and feasibility of online attacks are defined by security mechanisms implemented by application such as rate limiting authentication requests per user, IP address, etc. As well as by overall performance of network infrastructure and application.

===Offline Attacks===
If attacker have got a passwords file or a database dump or a captured traffic (e.g. Kerberos ticket or WiFi frames) and passwords are protected with some kind of crypto then attacker may mount so called offline attack.

The speed of offline attack is defined by resources available to attacker as well as robustness of methods used to protect user's passwords. In many cases the difference is speed between online and offline mode is order of magnitude in favour of offline mode.

===Depth vs. Breadth===
In context of password policy discussions it might be useful to distinguish ''targeted'' and ''untargeted'' attacks by attacker's primary goal:
; Targeted (depth-first) : Attacker needs to guess password of a specific user.
; Untargeted (breadth-first) : Attacker would be satisfied to find out any password of any account or want to collect as much valid credentials as possible.

===Password Leaks===
There are plenty of threats for passwords confidentiality that have no relation to guessing techniques at all. Examples are:
* Phishing and social engineering attacks;
* Malware installed on users devices;
* Capturing passwords during transmissions over insecure channels;
* Etc.

===Password Policy as a Mitigation to Passwords Threats===
TODO

==Links==
# [http://openwall.info/wiki/passwdqc/policy Password strength policy considerations.] by Solar Designer
# [http://research.microsoft.com/apps/pubs/?id=227130 An Administrator’s Guide to Internet Password Research. Dinei Florencio ˆ, Cormac Herley, and Paul C. van Oorschot. 2014]
# [http://research.microsoft.com/apps/pubs/?id=250408 Passwords and the Evolution of Imperfect Authentication. Joe Bonneau, Cormac Herley, Paul C. van Oorschot, and Frank Stajano. 2015]

Password policy (Draft)

2015-11-20T23:17:47Z

Adedov: Created page with "'''This document is an attempt to write draft replacement for Password length & complexity page.''' ==What Is Password Policy== TODO ==Threat Model== There are three mai..."

User:Adedov

2015-11-20T23:15:47Z

Adedov:

I was born in central Siberia, Russia in 1978. I lived in various places at Siberia till 2010 then moved to Moscow.

I am software developer at Parallels [http://cp.parallels.com] since 2005. In 2012 started working on product security. Also an open source developer and occasional researcher.

Personal projects
* XML-RPC library for C++, [http://libiqxmlrpc.wikidot.com Libiqxmlrpc]
* [http://password-policy-testing.wikidot.com/ Password Policy Testing Framework]

Twitter: @brutemorse

Github: [https://github.com/adedov adedov]

==Drafts==
* [[Password policy (Draft)]]

User:Adedov

2015-11-20T22:39:14Z

Adedov:

Talk:Password length & complexity

2015-11-14T12:05:39Z

Adedov:

Several proposals for addition into article:
# Add threat model and a role of password complexity as possible mitigation:
#* Online guessing attacks
#* Offline guessing attacks
#* Breadth vs. targeted attacks
#* Relation between password storage and effectiveness of password policy[1]
# Psychology acceptance issues
#* If account is important for a system (e.g. staff vs. customer accounts, privileged vs. unprivileged, etc).
#* If service is important for a user (e.g. personal backup vs. bulletin board vs. movie ranking site vs. banking service, etc).
#* Theoretical limit for memorable passwords entropy per user/site, per user/all sites he use.
#* Password entering usability concerns (mobiles vs. desktop).
#* Presence of multiple factors of AuthN.
# Password policy implementations considerations
#* Preference length over "complexity" [link needed]
#* Gamification is a friend [link needed]
#* Heuristic-based over formal polices [2,3]
#* Known password blacklists
# List of approved password polices
#* Strong polices: passwdqc, zxcvbn
#* Liberal polices?
#* libpathwell?
# Other aspects of password policy
#* Password expiration (pros and cons) [links needed]
#* Password history (pros and cons)
#* Client-side vs server-side
# Password generation
#* Link to entropy of random passwords on Wikipedia
#* Pronounceable passwords
# Something else?

Btw, Wikipedia's [https://en.wikipedia.org/wiki/Password_strength Password Strength] page is good enough but have no direct recommendations for developers. It is rather good compilation of different opinions and researches. At least links are very useful.

Materials:

* [1] [http://research.microsoft.com/apps/pubs/?id=227130 An Administrator’s Guide to Internet Password Research] by Dinei Florencio ˆ, Cormac Herley, and Paul C. van Oorschot
* [2] [https://www.youtube.com/watch?v=zUM7i8fsf0g Your Password Complexity Requirements are Worthless] by KoreLogic
* [3] [http://password-policy-testing.wikidot.com/results Testing Password Polices] by adedov@

--[[User:Adedov|Adedov]] ([[User talk:Adedov|talk]]) 06:05, 14 November 2015 (CST)
----

The overall content is correct, but I have the following remarks :

1. I corrected some syntactical errors in the text. For example, "is" was missing in the sentence "it is the most common form", in the introduction.

2. The introduction could insist on the idea that passwords are basically a means of authenticating users of a Web application, among other means, and that the choice of passwords or a stronger means like two-factors authentication really depends on the security needs of an application, based on risk evaluation and security specifications in the conception phase.

3. In the introduction about the "Pros" and "Cons" of passwords, I would add in the "Cons" that we all suffer from having to manage and remember too many passwords. For a new Web application, one should consider the possibility of relying on a more global identity management system (such as some sort of "single sign on" or "reduced sign on" set for all or at least many applications in the corporation), instead of trying to generate yet another password.

4. I think the details of password length, password complexity and password history should not be fixed too precisely, because it really depends on the security policies of each organization. The main point in general is that in security policies, there must be rules for password length (a minimum length should be defined), password complexity (the minimum complexity of passwords should be described) and password history (the minimum number of old passwords to check should be defined).

5. I would not present managing the history of passwords as a "nice to have" feature, but rather as a mandatory feature.

Philippe Curmin

== How to avoid similar passwords? ==

In order to hinder users from using similar passwords or passwords with simple counters ("test1" -> "test2") it would be nice to implement the [http://en.wikipedia.org/wiki/Levenshtein_distance Levenshtein Distance] for the change of passwords and only allow those with at least a minimum distance.

The problem with the distance function is that I need to know the old password, which I shouldn't. If I save passwords as hashes the function doesn't work anymore.

Is there already an algorithm to compare passwords without saving them as plain text? I can imagine something like a function that saves the structure of the phrase, i.e. "test1" consists of 4 alphabetical lowercase signs and one number - the same as in "test2". But also in "ak9Me". So it needs to be a bit more sophisticated.

Any ideas?

== Password lifetime criteria ==

Is there any advice or direction on how often a system should require a password to be changed?

Passwords that change too often are much less likely to be committed to memory, which leads to more use of the dreaded sticky note on the monitor.
For instance, if a system typically has monthly access from users, and has a 90 day password change policy, this would lead to each password only being used ~3 times before requiring change.

Dave Elton

User:Adedov

2015-11-13T13:57:09Z

Adedov:

User:Adedov

2015-11-13T13:56:34Z

Adedov:

Talk:Password Storage Cheat Sheet

2015-11-13T13:28:57Z

Adedov:

Suggest take in account planned/actual scale of a system to protect. Bigger systems probably need more layers of defense, like additional authN server + secret salt (local parameters) + traditional KDF for storage. See Solar Designer's [http://openwall.com/presentations/YaC2012-Password-Hashing-At-Scale/ slides] from Yac 2012 (unfortunately, there is no English video).

--[[User:Adedov|Adedov]] ([[User talk:Adedov|talk]]) 07:28, 13 November 2015 (CST)
----

Increasing work factor with PBKDF2 etc. can result in an application-level DoS vector. This can be abused in a passively distributed manner by inducing CSRF authentication attempts and hence standard CSRF mitigation should be applied to authentication systems too. Mitigating automated DoS attacks on this vector can be achieved with CAPTCHA but which users should be required to complete a CAPTCHA isn't as simple; linking it to a session and failed authentication attempts will not work as an automated attack can simply request a new session token. Perhaps it should be linked to IP or subnet?

--[[User:Arran Schlosberg|Arran Schlosberg]] , 19 Feb 2014 (UTC)
----

Setting a unlimited length for passwords can be an easy DOS vector. http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/

--[[User:jmanico|Jim Manico]] , 16 Sept 2013 (UTC)
----

More on the previous dicussions on secret salts. They are usually referred to as pepper on practice. The advantage of having a pepper for the passwords is that you can keep them on the web server. Thus, if the hacker has access to the database data and he has access to all hashed passwords (doesn't matter if they are created using PBKDF2, bcrypt or scrypt, or even simple salt+sha2), he still needs to also hack the web server to obtain the pepper, or fixed salt. It isn't cryptographically significant, but it adds yet another layer to the information the hacker has to obtain before starting to do the brute force.
I think it would be nice if it was possible to add it to the cheat sheet.

--[[User:Manuel Aude Morales|Manuel Aude Morales]] , 18 March 2013 (UTC)
----

I was considering adding bcrypt to the article. I checked previous versions and noticed it was in it on January, but it was taken out during editions in March. From my knowledge, bcrypt is still a widely recommended adaptative hashing function. While it has limitations (particularly, a 55 bytes limitation) and doesn't protect to all hardware accelerated attacks, it does protect against GPU and works as good as PBKDF2 for most cases. Also, scrypt hasn't existed for nearly as much as bcrypt, and thus it isn't as widely tested or supported by platforms.

Would it be ok to add a table making a comparison between PBKDF2, bcrypt and scrypt, with suggestions on when to use (and clarifying that the three are valid options)?
--[[User:Manuel Aude Morales|Manuel Aude Morales]] , 18 March 2013 (UTC)
----

Is there any utility in incuding credential data in the input to the protective function? I don't understand what it adds, given a sufficiently random salt. [[User:James Sanderson|James Sanderson]] ([[User talk:James Sanderson|talk]]) 17:25, 2 July 2014 (CDT)

Talk:Logging Cheat Sheet

2015-07-17T13:06:31Z

Adedov: Created page with "Why other cheatsheets bar at right? It conflicts mobile wiki viewers in particular and mobile browsers in general. --~~~~"

Why other cheatsheets bar at right? It conflicts mobile wiki viewers in particular and mobile browsers in general. --[[User:Adedov|Adedov]] ([[User talk:Adedov|talk]]) 08:06, 17 July 2015 (CDT)

Error Handling, Auditing and Logging

2015-07-17T12:32:26Z

Adedov: /* Error Handling */ PHP is not "functional" language

[[Guide Table of Contents|Development Guide Table of Contents]]__TOC__

==Objective ==

Many industries are required by legal and regulatory requirements to be:

* Auditable – all activities that affect user state or balances are formally tracked

* Traceable – it’s possible to determine where an activity occurs in all tiers of the application

* High integrity – logs cannot be overwritten or tampered with by local or remote users

Well-written applications will dual-purpose logs and activity traces for audit and monitoring, and make it easy to track a transaction without excessive effort or access to the system. They should possess the ability to easily track or identify potential fraud or anomalies end-to-end.

==Environments Affected ==

All.

==Relevant COBIT Topics ==

DS11 – Manage Data – All sections should be reviewed, but in particular:

DS11.4 Source data error handling

DS11.8 Data input error handling

==Description ==

Error handling, debug messages, auditing and logging are different aspects of the same topic: how to track events within an application:

==Best practices ==

* Fail safe – do not fail open

* Dual purpose logs

* Audit logs are legally protected – protect them

* Reports and search logs using a read-only copy or complete replica

==Error Handling ==

Error handling takes two forms: structured exception handling and functional error checking. Structured exception handling is always preferred as it is easier to cover 100% of code. On the other hand it is very hard to cover 100% of all errors in languages that do not have exceptions, such as PHP 4. Code that covers 100% of errors is extraordinarily verbose and difficult to read, and can contain subtle bugs and errors in the error handling code itself.

Motivated attackers like to see error messages as they might leak information that leads to further attacks, or may leak privacy related information. Web application error handling is rarely robust enough to survive a penetration test.

Applications should always fail safe. If an application fails to an unknown state, it is likely that an attacker may be able to exploit this indeterminate state to access unauthorized functionality, or worse create, modify or destroy data.

===Fail safe ===

* Inspect the application’s fatal error handler.

* Does it fail safe? If so, how?

* Is the fatal error handler called frequently enough?

* What happens to in-flight transactions and ephemeral data?

===Debug errors ===

* Does production code contain debug error handlers or messages?

* If the language is a scripting language without effective pre-processing or compilation, can the debug flag be turned on in the browser?

* Do the debug messages leak privacy related information, or information that may lead to further successful attack?

===Exception handling ===

* Does the code use structured exception handlers (try {} catch {} etc) or function-based error handling?

* If the code uses function-based error handling, does it check every return value and handle the error appropriately?

* Would fuzz injection against the average interface fail?

===Functional return values ===

Many languages indicate an error condition by return value. E.g.:

<pre>
$query = mysql_query(“SELECT * FROM table WHERE id=4”, $conn);

if ( $query === false ) {

// error

}
</pre>

* Are all functional errors checked? If not, what can go wrong?

==Detailed error messages ==

Detailed error messages provide attackers with a mountain of useful information.

===How to determine if you are vulnerable ===

* Are detailed error messages turned on?

* Do the detailed error messages leak information that may be used to stage a further attack, or leak privacy related information?

* Does the browser cache the error message?

===How to protect yourself ===

Ensure that your application has a “safe mode” to which it can return if something truly unexpected occurs. If all else fails, log the user out and close the browser window.

Production code should not be capable of producing debug messages. If it does, debug mode should be triggered by editing a file or configuration option on the server. In particular, debug should not enabled be an option in the application itself.

If the framework or language has a structured exception handler (i.e. try {} catch {}), it should be used in preference to functional error handling.

If the application uses functional error handling, its use must be comprehensive and thorough.

Detailed error messages, such as stack traces or leaking privacy related information, should never be presented to the user. Instead a generic error message should be used. This includes HTTP status response codes (i.e. 404 or 500 Internal Server error).

==Logging ==

===Where to log to? ===

Logs should be written so that the log file attributes are such that only new information can be written (older records cannot be rewritten or deleted). For added security, logs should also be written to a write once / read many device such as a CD-R.

Copies of log files should be made at regular intervals depending on volume and size (daily, weekly, monthly, etc.). A common naming convention should be adopted with regards to logs, making them easier to index. Verification that logging is still actively working is overlooked surprisingly often, and can be accomplished via a simple cron job!

Make sure data is not overwritten.

Log files should be copied and moved to permanent storage and incorporated into the organization's overall backup strategy.

Log files and media should be deleted and disposed of properly and incorporated into an organization's shredding or secure media disposal plan. Reports should be generated on a regular basis, including error reporting and anomaly detection trending.

Be sure to keep logs safe and confidential even when backed up.

===Handling ===

Logs can be fed into real time intrusion detection and performance and system monitoring tools. All logging components should be synced with a timeserver so that all logging can be consolidated effectively without latency errors. This time server should be hardened and should not provide any other services to the network.

No manipulation, no deletion while analyzing.

===General Debugging ===

Logs are useful in reconstructing events after a problem has occurred, security related or not. Event reconstruction can allow a security administrator to determine the full extent of an intruder's activities and expedite the recovery process.

===Forensics evidence ===

Logs may in some cases be needed in legal proceedings to prove wrongdoing. In this case, the actual handling of the log data is crucial.

===Attack detection ===

Logs are often the only record that suspicious behavior is taking place: Therefore logs can sometimes be fed real-time directly into intrusion detection systems.

===Quality of service ===

Repetitive polls can be protocolled so that network outages or server shutdowns get protocolled and the behavior can either be analyzed later on or a responsible person can take immediate actions.

===Proof of validity ===

Application developers sometimes write logs to prove to customers that their applications are behaving as expected.

* Required by law or corporate policies.

* Logs can provide individual accountability in the web application system universe by tracking a user's actions.

It can be corporate policy or local law to be required to (for example) save header information of all application transactions. These logs must then be kept safe and confidential for six months before they can be deleted.

The points from above show all different motivations and result in different requirements and strategies. This means, that before we can implement a logging mechanism into an application or system, we have to know the requirements and their later usage. If we fail in doing so this can lead to unintentional results.

Failure to enable or design the proper event logging mechanisms in the web application may undermine an organization's ability to detect unauthorized access attempts, and the extent to which these attempts may or may not have succeeded. We will look into the most common attack methods, design and implementation errors, as well as the mitigation strategies later on in this chapter.

There is another reason why the logging mechanism must be planned before implementation. In some countries, laws define what kind of personal information is allowed to be not only logged but also analyzed. For example, in Switzerland, companies are not allowed to log personal information of their employees (like what they do on the internet or what they write in their emails). So if a company wants to log a worker's surfing habits, the corporation needs to inform her of their plans in advance.

This leads to the requirement of having anonymized logs or de-personalized logs with the ability to re-personalized them later on if need be. If an unauthorized person has access to (legally) personalized logs, the corporation is acting unlawful. So there can be a few (not only) legal traps that must be kept in mind.

===Logging types ===

Logs can contain different kinds of data. The selection of the data used is normally affected by the motivation leading to the logging. This section contains information about the different types of logging information and the reasons why we could want to log them.

In general, the logging features include appropriate debugging information such as time of event, initiating process or owner of process, and a detailed description of the event. The following are types of system events that can be logged in an application. It depends on the particular application or system and the needs to decide which of these will be used in the logs:

* Reading of data file access and what kind of data is read. This not only allows to see if data was read but also by whom and when.

* Writing of data logs also where and with what mode (append, replace) data was written. This can be used to see if data was overwritten or if a program is writing at all.

* Modification of any data characteristics, including access control permissions or labels, location in database or file system, or data ownership. Administrators can detect if their configurations were changed.

* Administrative functions and changes in configuration regardless of overlap (account management actions, viewing any user's data, enabling or disabling logging, etc.)

* Miscellaneous debugging information that can be enabled or disabled on the fly.

* All authorization attempts (include time) like success/failure, resource or function being authorized, and the user requesting authorization. We can detect password guessing with these logs. These kinds of logs can be fed into an Intrusion Detection system that will detect anomalies.

* Deletion of any data (object). Sometimes applications are required to have some sort of versioning in which the deletion process can be cancelled.

* Network communications (bind, connect, accept, etc.). With this information an Intrusion Detection system can detect port scanning and brute force attacks.

* All authentication events (logging in, logging out, failed logins, etc.) that allow to detect brute force and guessing attacks too.

==Noise ==

Noise is intentionally invoking security errors to fill an error log with entries (noise) that hide the incriminating evidence of a successful intrusion. When the administrator or log parser application reviews the logs, there is every chance that they will summarize the volume of log entries as a denial of service attempt rather than identifying the 'needle in the haystack'.

===How to protect yourself ===

This is difficult since applications usually offer an unimpeded route to functions capable of generating log events. If you can deploy an intelligent device or application component that can shun an attacker after repeated attempts, then that would be beneficial. Failing that, an error log audit tool that can reduce the bulk of the noise, based on repetition of events or originating from the same source for example. It is also useful if the log viewer can display the events in order of severity level, rather than just time based.

==Cover Tracks ==

The top prize in logging mechanism attacks goes to the contender who can delete or manipulate log entries at a granular level, "as though the event never even happened!". Intrusion and deployment of rootkits allows an attacker to utilize specialized tools that may assist or automate the manipulation of known log files. In most cases, log files may only be manipulated by users with root / administrator privileges, or via approved log manipulation applications. As a general rule, logging mechanisms should aim to prevent manipulation at a granular level since an attacker can hide their tracks for a considerable length of time without being detected. Simple question; if you were being compromised by an attacker, would the intrusion be more obvious if your log file was abnormally large or small, or if it appeared like every other day's log?

===How to protect yourself ===

Assign log files the highest security protection, providing reassurance that you always have an effective 'black box' recorder if things go wrong. This includes:

*Applications should not run with Administrator, or root-level privileges. This is the main cause of log file manipulation success since super users typically have full file system access. Assume the worst case scenario and suppose your application is exploited. Would there be any other security layers in place to prevent the application's user privileges from manipulating the log file to cover tracks?

*Ensuring that access privileges protecting the log files are restrictive, reducing the majority of operations against the log file to alter and read.

*Ensuring that log files are assigned object names that are not obvious and stored in a safe location of the file system.

*Writing log files using publicly or formally scrutinized techniques in an attempt to reduce the risk associated with reverse engineering or log file manipulation.

*Writing log files to read-only media (where event log integrity is of critical importance).

*Use of hashing technology to create digital fingerprints. The idea is that if an attacker does manipulate the log file, then the digital fingerprint will not match and an alert generated.

*Use of host-based IDS technology where normal behavioral patterns can be 'set in stone'. Attempts by attackers to update the log file through anything but the normal approved flow would generate an exception and the intrusion can be detected and blocked. This is one security control that can safeguard against simplistic administrator attempts at modifications.

==False Alarms ==

Taking cue from the classic 1966 film "How to Steal a Million", or similarly the fable of Aesop; "The Boy Who Cried Wolf", be wary of repeated false alarms, since this may represent an attacker's actions in trying to fool the security administrator into thinking that the technology is faulty and not to be trusted until it can be fixed.

===How to protect yourself ===

Simply be aware of this type of attack, take every security violation seriously, always get to the bottom of the cause event log errors rather, and don't just dismiss errors unless you can be completely sure that you know it to be a technical problem.

===Denial of Service ===

By repeatedly hitting an application with requests that cause log entries, multiply this by ten thousand, and the result is that you have a large log file and a possible headache for the security administrator. Where log files are configured with a fixed allocation size, then once full, all logging will stop and an attacker has effectively denied service to your logging mechanism. Worse still, if there is no maximum log file size, then an attacker has the ability to completely fill the hard drive partition and potentially deny service to the entire system. This is becoming more of a rarity though with the increasing size of today's hard disks.

===How to protect yourself ===

The main defense against this type of attack are to increase the maximum log file size to a value that is unlikely to be reached, place the log file on a separate partition to that of the operating system or other critical applications and best of all, try to deploy some kind of system monitoring application that can set a threshold against your log file size and/or activity and issue an alert if an attack of this nature is underway.

==Destruction ==

Following the same scenario as the Denial of Service above, if a log file is configured to cycle round overwriting old entries when full, then an attacker has the potential to do the evil deed and then set a log generation script into action in an attempt to eventually overwrite the incriminating log entries, thus destroying them.

If all else fails, then an attacker may simply choose to cover their tracks by purging all log file entries, assuming they have the privileges to perform such actions. This attack would most likely involve calling the log file management program and issuing the command to clear the log, or it may be easier to simply delete the object which is receiving log event updates (in most cases, this object will be locked by the application). This type of attack does make an intrusion obvious assuming that log files are being regularly monitored, and does have a tendency to cause panic as system administrators and managers realize they have nothing upon which to base an investigation on.

===How to protect yourself ===

Following most of the techniques suggested above will provide good protection against this attack. Keep in mind two things:

*Administrative users of the system should be well trained in log file management and review. 'Ad-hoc' clearing of log files is never advised and an archive should always be taken. Too many times a log file is cleared, perhaps to assist in a technical problem, erasing the history of events for possible future investigative purposes.

*An empty security log does not necessarily mean that you should pick up the phone and fly the forensics team in. In some cases, security logging is not turned on by default and it is up to you to make sure that it is. Also, make sure it is logging at the right level of detail and benchmark the errors against an established baseline in order measure what is considered 'normal' activity.

==Audit Trails ==

Audit trails are legally protected in many countries, and should be logged into high integrity destinations to prevent casual and motivated tampering and destruction.

===How to determine if you are vulnerable ===

* Do the logs transit in the clear between the logging host and the destination?

* Do the logs have a HMAC or similar tamper proofing mechanism to prevent change from the time of the logging activity to when it is reviewed?

* Can relevant logs be easily extracted in a legally sound fashion to assist with prosecutions?

===How to protect yourself ===

* Only audit truly important events – you have to keep audit trails for a long time, and debug or informational messages are wasteful

* Log centrally as appropriate and ensure primary audit trails are not kept on vulnerable systems, particularly front end web servers

* Only review copies of the logs, not the actual logs themselves

* Ensure that audit logs are sent to trusted systems

* For highly protected systems, use write-once media or similar to provide trust worthy long term log repositories

* For highly protected systems, ensure there is end-to-end trust in the logging mechanism. World writeable logs, logging agents without credentials (such as SNMP traps, syslog etc) are legally vulnerable to being excluded from prosecution

==Further Reading ==

* Oracle Auditing

http://www.dba-oracle.com/t_audit_table_command.htm

* Sarbanes Oxley for IT security

http://www.securityfocus.com/columnists/322

* Java Logging Overview
http://java.sun.com/javase/6/docs/technotes/guides/logging/overview.html

==Error Handling and Logging ==

All applications have failures – whether they occur during compilation or runtime. Most programming languages will throw runtime exceptions for illegally executing code (e.g. syntax errors) often in the form of cryptic system messages. These failures and resulting system messages can lead to several security risks if not handled properly including; enumeration, buffer attacks, sensitive information disclosure, etc. If an attack occurs it is important that forensics personnel be able to trace the attacker’s tracks via adequate logging.

ColdFusion provides structured exception handling and logging tools. These tools can help developers customize error handling to prevent unwanted disclosure, and provide customized logging for error tracking and audit trails. These tools should be combined with web server, J2EE application server, and operating system tools to create the full system/application security overview.

'''Error Handling'''

Hackers can use the information exposed by error messages. Even missing templates errors (HTTP 404) can expose your server to attacks (e.g. buffer overflow, XSS, etc.). If you enable the Robust Exception Information debugging option, ColdFusion will display:

Physical path of template

URI of template

Line number and line snippet

SQL statement used (if any)

Data source name (if any)

Java stack trace

ColdFusion provides tags and functions for developers to use to customize error handling. Administrators can specify default templates in the ColdFusion Administrator (CFAM) to handle unknown or unhandled exceptions. ColdFusion’s structure exception handling works in the following order:

Template level (ColdFusion templates and components)

ColdFusion exception handling tags: cftry, cfcatch, cfthrow, and cfrethrow

try and catch statements in CFScript

Application level (Application.cfc/cfm)

Specify custom templates for individual exceptions types with the cferror tag

Application.cfc onError method to handle uncaught application exceptions

System level (ColdFusion Administrator settings)

Missing Template Handler execute when a requested ColdFusion template is not found

Site-wide Error Handler executes globally for all unhandled exceptions on the server

'''Best Practices '''

*Do not allow exceptions to go unhandled

*Do not allow any exceptions to reach the browser

*Display custom error pages to users with an email link for feedback

*Do not enable “Robust Exception Information” in production.

*Specify custom pages for ColdFusion to display in each of the following cases:
**When a ColdFusion page is missing (the Missing Template Handler page)
**When an otherwise-unhandled exception error occurs during the processing of a page (the Site-wide Error Handler page)
**You specify these pages on the Settings page in the Server Settings are in the ColdFusion MX Administrator; for more information, see the ColdFusion MX Administrator Help.

*Use the cferror tag to specify ColdFusion pages to handle specific types of errors.

*Use the cftry, cfcatch, cfthrow, and cfrethrow tags to catch and handle exception errors directly on the page where they occur.

*In CFScript, use the try and catch statements to handle exceptions.

*Use the onError event in Application.cfc to handle exception errors that are not handled by try/catch code on the application pages.

'''Logging'''

Log files can help with application debugging and provide audit trails for attack detection. ColdFusion provides several logs for different server functions. It leverages the Apache Log4j libraries for customized logging. It also provides logging tags to assist in application debugging.

The following is a partial list of ColdFusion log files and their descriptions''' '''

{| border=1

|| Log file || Description

|-

|| application.log || Records every ColdFusion MX error reported to a user. Application page errors, including ColdFusion MX syntax, ODBC, and SQL errors, are written to this log file.

|-

|| exception.log || Records stack traces for exceptions that occur in ColdFusion.

|-

|| scheduler.log || Records scheduled events that have been submitted for execution. Indicates whether task submission was initiated and whether it succeeded. Provides the scheduled page URL, the date and time executed, and a task ID.

|-

|| server.log || Records start up messages and errors for ColdFusion MX.

|-

|| customtag.log || Records errors generated in custom tag processing.

|-

|| mail.log || Records errors generated by an SMTP mail server.

|-

|| mailsent.log || Records messages sent by ColdFusion MX.

|-

|| flash.log || Records entries for Macromedia Flash Remoting.

|-

|}

The CFAM contains the Logging Settings and log viewer screens. Administrators can configure the log directory, maximum log file size, and maximum number of archives. It also allows administrators to log slow running pages, CORBA calls, and scheduled task execution. The log viewer allows viewing, filtering, and searching of any log files in the log directory (default is cf_root/logs). Administrators can archive, save, and delete log files as well.

The cflog and cftrace tags allow developers to create customized logging. <cflog> can write custom messages to the Application.log, Scheduler.log, or a custom log file. The custom log file must be in the default log directory – if it does not exist ColdFusion will create it. <cftrace> tracks execution times, logic flow, and variable at the time the tag executes. It records the data in the cftrace.log (in the default logs directory) and can display this info either inline or in the debugging output of the current page request. Use <cflog> to write custom error messages, track user logins, and record user activity to a custom log file. Use <cftrace> to track variables and application state within running requests.

'''Best Practices'''

*Use <cflog> for customized logging

*Incorporate into custom error handling

*Record application specific messages

*Actively monitor and fix errors in ColdFusion’s logs

*Optimize logging settings

*Rotate log files to keep them current

*Keep files size manageable

*Enable logging of slow running pages

*Set the time interval lower than the configured Timeout Request value in the CFAM Settings screen

*Long running page timings are recorded in the server.log

*Use <cftrace> sparingly for audit trails

*Use with inline=“false”

*Use it to track user input – Form and/or URL variables

'''''Best Practices in Action'''''

The following code adds error handling and logging to the dbLogin and logout methods in the code from Authentication section.

<pre>

<cffunction name="dblogin" access="private" output="false" returntype="struct">

<cfargument name="strUserName" required="true" type="string">

<cfargument name="strPassword" required="true" type="string">

<cfset var retargs = StructNew()>

<cftry>

<cfif IsValid("regex", uUserName, "[A-Za-z0-9%]*") AND IsValid("regex", uPassword, "[A-Za-z0-9%]*")>

<cfquery name="loginQuery" dataSource="#Application.DB#" >

SELECT hashed_password, salt

FROM UserTable

WHERE UserName =

<cfqueryparam value="#strUserName#" cfsqltype="CF_SQL_VARCHAR" maxlength="25">

</cfquery>

<cfif loginQuery.hashed_password EQ Hash(strPassword & loginQuery.salt, "SHA-256" )>

<cfset retargs.authenticated="YES">

<cfset Session.UserName = strUserName>

<cflog text="#getAuthUser()# has logged in!"

type="Information"

file="access"

application="yes">



<cfelse>

<cfset retargs.authenticated="NO">

</cfif>

<cfelse>

<cfset retargs.authenticated="NO">

</cfif>

<cfcatch type="database">

<cflog text="Error in dbLogin(). #cfcatch.details#"

type="Error"

log="Application"

application="yes">

<cfset retargs.authenticated="NO">

<cfreturn retargs>

</cfcatch>

</cftry>

<cfreturn retargs>

</cffunction>

<cffunction name="logout" access="remote" output="true">

<cfargument name="logintype" type="string" required="yes">

<cfif isDefined("form.logout")>

<cflogout>

<cfset StructClear(Session)>

<cflog text="#getAuthUser()# has been logged out."

type="Information"

file="access"

application="yes">

<cfif arguments.logintype eq "challenge">

<cfset foo = closeBrowser()>

<cfelse>



<cflocation url="login.cfm">

</cfif>

</cfif>

</cffunction>

<cffunction name="dblogin" access="private" output="false" returntype="struct">

<cfargument name="strUserName" required="true" type="string">

<cfargument name="strPassword" required="true" type="string">

<cfset var retargs = StructNew()>

<cftry>

<cfif IsValid("regex", uUserName, "[A-Za-z0-9%]*") AND IsValid("regex", uPassword, "[A-Za-z0-9%]*")>

<cfquery name="loginQuery" dataSource="#Application.DB#" >

SELECT hashed_password, salt

FROM UserTable

WHERE UserName =

<cfqueryparam value="#strUserName#" cfsqltype="CF_SQL_VARCHAR" maxlength="25">

</cfquery>

<cfif loginQuery.hashed_password EQ Hash(strPassword & loginQuery.salt, "SHA-256" )>

<cfset retargs.authenticated="YES">

<cfset Session.UserName = strUserName>

<cflog text="#getAuthUser()# has logged in!"

type="Information"

file="access"

application="yes">



<cfelse>

<cfset retargs.authenticated="NO">

</cfif>

<cfelse>

<cfset retargs.authenticated="NO">

</cfif>

<cfcatch type="database">

<cflog text="Error in dbLogin(). #cfcatch.details#"

type="Error"

log="Application"

application="yes">

<cfset retargs.authenticated="NO">

<cfreturn retargs>

</cfcatch>

</cftry>

<cfreturn retargs>

</cffunction>

<cffunction name="logout" access="remote" output="true">

<cfargument name="logintype" type="string" required="yes">

<cfif isDefined("form.logout")>

<cflogout>

<cfset StructClear(Session)>

<cflog text="#getAuthUser()# has been logged out."

type="Information"

file="access"

application="yes">

<cfif arguments.logintype eq "challenge">

<cfset foo = closeBrowser()>

<cfelse>



<cflocation url="login.cfm">

</cfif>

</cfif>

</cffunction>

</pre>

[[Guide Table of Contents|Development Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]
[[Category:Error Handling]]
[[Category:Logging]]
[[Category:OWASP Logging Project]]

Blocking Brute Force Attacks

2015-03-18T07:45:22Z

Adedov: /* Device Cookies */

== Blocking Brute Force Attacks ==

A common threat web developers face is a password-guessing attack known as a brute force attack. A brute-force attack is an attempt to discover a password by systematically trying every possible combination of letters, numbers, and symbols until you discover the one correct combination that works. If your web site requires user authentication, you are a good target for a brute-force attack.

An attacker can always discover a password through a brute-force attack, but the downside is that it could take years to find it. Depending on the password's length and complexity, there could be trillions of possible combinations. To speed things up a bit, a brute-force attack could start with dictionary words or slightly modified dictionary words because most people will use those rather than a completely random password. These attacks are called dictionary attacks or hybrid brute-force attacks. Brute-force attacks put user accounts at risk and flood your site with unnecessary traffic.

Hackers launch brute-force attacks using widely available tools that utilize wordlists and smart rulesets to intelligently and automatically guess user passwords. Although such attacks are easy to detect, they are not so easy to prevent. For example, many HTTP brute-force tools can relay requests through a list of open proxy servers. Since each request appears to come from a different IP address, you cannot block these attacks simply by blocking the IP address. To further complicate things, some tools try a different username and password on each attempt, so you cannot lock out a single account for failed password attempts.

==Locking Accounts==

The most obvious way to block brute-force attacks is to simply lock out accounts after a defined number of incorrect password attempts. Account lockouts can last a specific duration, such as one hour, or the accounts could remain locked until manually unlocked by an administrator. However, account lockout is not always the best solution, because someone could easily abuse the security measure and lock out hundreds of user accounts. In fact, some Web sites experience so many attacks that they are unable to enforce a lockout policy because they would constantly be unlocking customer accounts.

The problems with account lockouts are:

:* An attacker can cause a denial of service (DoS) by locking out large numbers of accounts.
:* Because you cannot lock out an account that does not exist, only valid account names will lock. An attacker could use this fact to harvest usernames from the site, depending on the error responses.
:* An attacker can cause a diversion by locking out many accounts and flooding the help desk with support calls.
:* An attacker can continuously lock out the same account, even seconds after an administrator unlocks it, effectively disabling the account.
:* Account lockout is ineffective against slow attacks that try only a few passwords every hour.
:* Account lockout is ineffective against attacks that try one password against a large list of usernames.
:* Account lockout is ineffective if the attacker is using a username/password combo list and guesses correctly on the first couple of attempts.
:* Powerful accounts such as administrator accounts often bypass lockout policy, but these are the most desirable accounts to attack. Some systems lock out administrator accounts only on network-based logins.
:* Even once you lock out an account, the attack may continue, consuming valuable human and computer resources.

Account lockout is sometimes effective, but only in controlled environments or in cases where the risk is so great that even continuous DoS attacks are preferable to account compromise. In most cases, however, account lockout is insufficient for stopping brute-force attacks. Consider, for example, an auction site on which several bidders are fighting over the same item. If the auction Web site enforced account lockouts, one bidder could simply lock the others' accounts in the last minute of the auction, preventing them from submitting any winning bids. An attacker could use the same technique to block critical financial transactions or e-mail communications.

==Device Cookies==

You may also consider locking out authentication attempts from known and unknown browsers or devices separately. The [[Slow Down Online Guessing Attacks with Device Cookies]] article proposes protocol for lockout mechanism based on information about if specific browser have been already used for successful login. The protocol is less susceptible to DoS attacks than plain account locking out and yet effective and easy to implement.

==Finding Other Countermeasures==

As described, account lockouts are usually not a practical solution, but there are other tricks to deal with brute force attacks. First, since the success of the attack is dependent on time, an easy solution is to inject random pauses when checking a password. Adding even a few seconds' pause can greatly slow a brute-force attack but will not bother most legitimate users as they log in to their accounts.

Note that although adding a delay could slow a single-threaded attack, it is less effective if the attacker sends multiple simultaneous authentication requests.

Another solution is to lock out an IP address with multiple failed logins. The problem with this solution is that you could inadvertently block large groups of users by blocking a proxy server used by an ISP or large company. Another problem is that many tools utilize proxy lists and send only a few requests from each IP address before moving on to the next. Using widely available open proxy lists at Web sites such as http://tools.rosinstrument.com/proxy/, an attacker could easily circumvent any IP blocking mechanism. Because most sites do not block after just one failed password, an attacker can use two or three attempts per proxy. An attacker with a list of 1,000 proxies can attempt 2,000 or 3,000 passwords without being blocked. Nevertheless, despite this method's weaknesses, Web sites that experience high numbers of attacks-adult Web sites in particular-do choose to block proxy IP addresses.

One simple yet surprisingly effective solution is to design your Web site not to use predictable behavior for failed passwords. For example, most Web sites return an "HTTP 401 error" code with a password failure, although some web sites instead return an "HTTP 200 SUCCESS" code but direct the user to a page explaining the failed password attempt. This fools some automated systems, but it is also easy to circumvent. A better solution might be to vary the behavior enough to eventually discourage all but the most dedicated hackers. You could, for example, use different error messages each time or sometimes let a user through to a page and then prompt him again for a password.

Some automated brute-force tools allow the attacker to set certain trigger strings to look for that indicate a failed password attempt. For example, if the resulting page contains the phrase "Bad username or password," the tool would know the credentials failed and would try the next in the list. A simple way to fool these tools is to include also those phrases as comments in the HTML source of the page they get when they successfully authenticate.

After one or two failed login attempts, you may want to prompt the user not only for the username and password but also to answer a secret question. This not only causes problems with automated attacks, it prevents an attacker from gaining access, even if they do get the username and password correct. You could also detect high numbers of attacks system-wide and under those conditions prompt all users for the answer to their secret questions.

Other techniques you might want to consider are:

:* For advanced users who want to protect their accounts from attack, give them the option to allow login only from certain IP addresses.
:*Assign unique login URLs to blocks of users so that not all users can access the site from the same URL.
:*Use a CAPTCHA to prevent automated attacks (see the sidebar "Using CAPTCHAs").
:*Instead of completely locking out an account, place it in a lockdown mode with limited capabilities.

Attackers can often circumvent many of these techniques by themselves, but by combining several techniques, you can significantly limit brute-force attacks. It might be difficult to stop an attacker who is determined to obtain a password specifically from your web site, but these techniques certainly can be effective against many attacks, including those from novice hackers. These techniques also require more work on the attacker's part, which gives you more opportunity to detect the attack and maybe even identify the attacker.

Although brute-force attacks are difficult to stop completely, they are easy to detect because each failed login attempt records an HTTP 401 status code in your Web server logs. It is important to monitor your log files for brute-force attacks-in particular, the intermingled 200 status codes that mean the attacker found a valid password.

Here are conditions that could indicate a brute-force attack or other account abuse:

:*Many failed logins from the same IP address
:*Logins with multiple usernames from the same IP address
:*Logins for a single account coming from many different IP addresses
:*Excessive usage and bandwidth consumption from a single use
:*Failed login attempts from alphabetically sequential usernames or passwords
:*Logins with a referring URL of someone's mail or IRC client
:*Referring URLs that contain the username and password in the format http://user:password@www.example.com/login.htm
:*If protecting an adult Web site, referring URLs of known password-sharing sites
:*Logins with suspicious passwords hackers commonly use, such as ownsyou (ownzyou), washere (wazhere), zealots, hacksyou, and the like

Brute force attacks are surprisingly difficult to stop completely, but with careful design and multiple countermeasures, you can limit your exposure to these attacks. Ultimately, the only best defense is to make sure that users follow basic rules for strong passwords: use long unpredictable passwords, avoid dictionary words, avoid reusing passwords, and change passwords regularly.

==Sidebar: Using CAPTCHAS==

A completely automated public Turing test to tell computers and humans apart, or CAPTCHA, is a program that allows you to distinguish between humans and computers. First widely used by Alta Vista to prevent automated search submissions, CAPTCHAs are particularly effective in stopping any kind of automated abuse, including brute-force attacks. They work by presenting some test that is easy for humans to pass but difficult for computers to pass; therefore, they can conclude with some certainty whether there is a human on the other end.

For a CAPTCHA to be effective, humans must be able to answer the test correctly as close to 100 percent of the time as possible. Computers must fail as close to 100 percent of the time as possible. Ez-gimpy (www.captcha.net/cgi-bin/ez-gimpy), perhaps the most commonly used CAPTCHA, presents the user with an obscured word that the user must type to pass the test. But researchers have since written pattern recognition programs that solve ez-gimpy with 92 percent accuracy. Although these researchers have not made their programs public, all it takes is one person to do so to make ez-gimpy mostly ineffective. Researchers at Carnegie Mellon's School of Computer Science continually work to improve and introduce new CAPTCHAs (see www.captcha.net/captchas).

If you are developing your own CAPTCHA, keep in mind that it is not how hard the question is that matters-it is how likely it is that a computer will get the correct answer. I once saw a CAPTCHA that presents the user with a picture of three zebras, with a multiple-choice question asking how many zebras were in the picture. To answer the question, you click one of three buttons. Although it would be very difficult for a computer program to both understand the question and interpret the picture, the program could just randomly guess any answer and get it correct 30 percent of the time. Although this might seem a satisfactory level of risk, it is by no means an effective CAPTCHA. If you run a free e-mail service and use a CAPTCHA such as this to prevent spammers from creating accounts in bulk, all they have to do is write a script to automatically create 1,000 accounts and expect on average that 333 of those attempts will be successful.

Nevertheless, a simple CAPTCHA may still be effective against brute-force attacks. When you combine the chance of an attacker sending a correct username and password guess with the chance of guessing the CAPTCHA correctly, combined with other techniques described in this chapter, even a simple CAPTCHA could prove effective.

===Figure 1: Password Authentication Delay: C#===

private void AuthenticateRequest(object obj, EventArgs ea)
{
HttpApplication objApp = (HttpApplication) obj;
HttpContext objContext = (HttpContext) objApp.Context;
// If user identity is not blank, pause for a random amount of time
if ( objApp.User.Identity.Name != "")
{
Random rand = new Random();
Thread.Sleep(rand.Next(minSeconds, maxSeconds) * 1000);
}
}

===Figure 2: Password Authentication Delay: VB.NET===

Public Sub AuthenticateRequest(ByVal obj As Object, ByVal ea As System.EventArgs)
Dim objApp As HttpApplication
Dim objContext As HttpContext
Dim ran As Random
objApp = obj
objContext = objApp.Context

' If user identity is not blank, pause for a random amount of time
If objApp.User.Identity.Name <> "" Then
ran = New Random
Thread.Sleep(ran.Next(ran.Next(minSeconds, maxSeconds) * 1000))
End If
End Sub

----

Mark Burnett (mburnett@xato.net) is an independent security consultant and author who specializes in Windows and web server security. He is an IIS MVP and author of Hacking the Code (Syngress Publishing).

Hacking the Code, written by Mark Burnett, is a unique book that walks you through the many security threats facing ASP.NET web developers. The book provides concise solutions, code examples, and security policy to address each of these threats threat.

[[Category:OWASP Columns]]
[[Category: Control]]

Slow Down Brute Force Attacks with Device Cookies

2015-03-04T14:18:05Z

Adedov: Add as alias with "Brute Force Attack" in title instead of "Online Guessing Attack"

#REDIRECT [[Slow_Down_Online_Guessing_Attacks_with_Device_Cookies]]

Talk:Blocking Brute Force Attacks

2015-03-02T08:53:31Z

Adedov: Created page with "Hi! I'd like to add link to Slow_Down_Online_Guessing_Attacks_with_Device_Cookies article into Locking Account section as alternative way to lock accounts that still resis..."

Hi! I'd like to add link to [[Slow_Down_Online_Guessing_Attacks_with_Device_Cookies]] article into Locking Account section as alternative way to lock accounts that still resistant to most modes of DoS attacks.
--[[User:Adedov|Adedov]] ([[User talk:Adedov|talk]]) 02:53, 2 March 2015 (CST)

Slow Down Online Guessing Attacks with Device Cookies

2015-02-26T09:37:11Z

Adedov: Change links to video.

[[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]).

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 106] 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.
|}

Slow Down Online Guessing Attacks with Device Cookies

2015-02-25T10:14:59Z

Adedov: Categorisation

[[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]).

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 106] 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.
|}

Slow Down Online Guessing Attacks with Device Cookies

2015-02-25T09:16:57Z

Adedov: /* 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]).

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 106] 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.
|}

Slow Down Online Guessing Attacks with Device Cookies

2015-02-24T21:50:34Z

Adedov: Initial version of article.

==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 106] 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.
|}

User:Adedov

2015-02-24T12:54:45Z

Adedov: