Generate strong tokens

Objective:

It should be extremely unlikely that an attacker with large amounts of bandwidth and processing resources should be able to guess a single valid token within the lifetime of its validity.

• Tokens should use a large set of possible values
• Should contain a strong source of pseudo-randomness
• Should only be an identifier used by the server to locate the relevant user object.
• Should contain no meaning or structure.
• Must use a cryptographically-secure source of randomness.
• For additional entropy, use:
  • Source IP and port number
  • User-agent from the request
  • Time of the request

Good formula for token generation:

• Concatenate (place the most variable towards the start):
  • Pseudorandom number
  • Request-specific data (e.g. IP)
  • Secret string from server that is generated each time the server is booted.
• SHA256 concatenated string.

Protect tokens throughout their lifecycle

• Only transmit over HTTPS (use the secure flag on any cookies).
• Never transmit in the URL. Always use POST requests.
• Implement logout and ensure it invalidates all tokens.
• Minimise session expiration time.
• Ensure that concurrent logons for the same user cannot occur. If an old session identifier is used, the user should be informed.
• If an admin function requires sessions to be viewed, the session token should not be displayed.
• The cookie path and domain should be as restrictive as possible.

To defend the session management mechanims against attack:

• Audit the application's codebase to remove any XSS vulnerabilities.
• If an arbitrary token is submitted, the in-session token should be cancelled and the user returned to the application's start page.
• To protect against CSRF, require a two-step confirmation or reauthentication before a high-risk transaction is carried out.
• CSRF can also be protected against by transmitting the token in a HTML hidden field rather than via a cookie.
• To mitigate against session fixation attacks, always create a fresh session after each authentication.

Per-page tokens

• A new token is created whenever a user requests an application page.
• Issues - stops backwards and forwards buttons from working.
• Can be used to monitor pages used by the customer and can be used to detect attempts to access functions out of order.

Log, monitor and alert

• Application should monitor requests that contain invalid tokens.
• Where an attacker attempts to generate lots of tokens as part of a guesssing attack, this will leave an obvious mark on the application log.
• To help mitigate against brute-force attacks, you can temporarily block IPs when a certain number of incorrect attempts have been made.
• Users should be alerted to anomalous events (e.g. concurrent logons).

Reactive session termination

• Where an anomoly is detected, the session can be easily terminated by revoking the token:
  • Modified hidden HTML field or URL parameter.
  • Anything that looks like an SQL injection or XSS attack.
  • Any input that would have been stopped by client-side validation.