Demystifying Web Authentication

I'm currently researching user authentication protocols for a website I'm developing. I would like to create an authentication cookie so users can stay logged in between pages.

Here is my first bash:

cookie = user_id|expiry_date|HMAC(user_id|expiry_date, k)

Where k is HMAC(user_id|expiry_date, sk) and sk is a 256 bit key only known to the server. HMAC is a SHA-256 hash. Note that '|' is a separator, not just concatenation.

This looks like this in PHP:

$key = hash_hmac('sha256', $user_id . '|' . $expiry_time, SECRET_KEY);
$digest = hash_hmac('sha256', $user_id . '|' . $expiry_ti开发者_StackOverflow社区me, $key);
$cookie = $user_id . '|' . $expiry_time . '|' . $digest;

I can see that it's vulnerable to Replay Attacks as stated in A Secure Cookie Protocol, but should be resistant to Volume Attacks, and Cryptographic Splicing.

THE QUESTION: Am I on the right lines here, or is there a massive vulnerability that I've missed? Is there a way to defend against Replay Attacks that works with dynamically assigned IP addresses and doesn't use sessions?

NOTES

The most recent material I have read:

Dos and Don'ts of Client Authentication on the Web aka Fu et al.

(https://pdos.csail.mit.edu/papers/webauth:sec10.pdf)

A Secure Cookie Protocol aka Liu et al.

(http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf)

which expands on the previous method

Hardened Stateless Session Cookies

(http://www.lightbluetouchpaper.org/2008/05/16/hardened-stateless-session-cookies/)

which also expands on the previous method.

As the subject is extremely complicated I'm am only looking for answers from security experts with real world experience in creating and breaking authentication schemes.

This is fine in general, I've done something similar in multiple apps. It is no more susceptible to replay attacks than session IDs already were. You can protect the tokens from leakage for replay by using SSL, same as you would for session IDs.

Minor suggestions:

• Put a field in your user data that gets updated on change-password (maybe password generation counter, or even just the random salt), and include that field in the token and signed-part. Then when the user changes their passwords they are also invalidating any other stolen tokens. Without this you are limited on how long you can reasonably allow a token to live before expiry.

• Put a scheme identifier in the token and signed-part, so that (a) you can have different types of token for different purposes (eg one for auth and one for XSRF protection), and (b) you can update the mechanism with a new version without having to invalidate all the old tokens.

• Ensure user_id is never re-used, to prevent a token being used to gain access to a different resource with the same ID.

• Pipe-delimiting assumes | can never appear in any of the field values. This probably works for the numeric values you are (presumably) dealing with, but you might at some point need a more involved format, eg URL-encoded name/value pairs.

• The double-HMAC doesn't seem to really get you much. Both brute force and cryptanalysis against HMAC-SHA256 are already implausibly hard by current understanding.

1. Unless your transactions/second will tax your hardware, I would only pass a hash in the cookie (i.e. leave out the user_id and expiry_date -- no sense giving the bad people any more information than you absolutely have to).

2. You could make some assumptions about what the next dynamic IP address should be, given the previous dynamic IP address (I don't have the details handy, alas). Hashing only the unchanging part of the dynamic IP address would help in verifying the user even when their IP address changes. This may or may not work, given the varieties of IP address allocation schemes.

3. You could get information about the system and hash that also -- in Linux, you could uname -a (but there are similar capabilities available for other OSes). Enough system information, and you might be able to skip using the (partial) IP address entirely. This technique will require some experimentation. Using only normally-browser-supplied system information would make it easier.

4. You need to think about how long your cookies should remain fresh. If you can live with people having to authenticate once daily, that would be easier on your system authentication coding than allowing people to authenticate only once a month (and so on).

I would consider this protocol as very weak!

1. your session-cookie is not a random source with high entropy.
2. The server must do asymmetric encryption on each page to verify a user.
3. The security of ANY user only relies in the security of the server-key sk.

The server-key SK is the most vulnerable part here. If anyone can guess it or steal it, he can login as a specific user.

So if sk is generated for each session and user, then why the hmac? I think you will use TLS anyway, if not, consider your protocol as broken because of replay attacks and eavesdropping in general!

If sk is generated for each user, but not for each session, it is similar to a 256bit password.

If sk is identical for all users, someone just has to crack 256 bits and he can log in as any user he wants. He only has to guess the id and the exiration date.

Have a look at digest-authentication. It's a per request authentication, specified by the rfc2617. It is secure for repay attacks using nonces, sent on each request. It is secure for eavesdropping using hashing. It is integrated in HTTP.