views:

69

answers:

1

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_time, $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.
(http://cookies.lcs.mit.edu/pubs.html)

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.

+1  A: 

This is the most thorough and practical solution I've seen to PHP authentication that's actually documented in real English.

The problem with security books is that the people who write them at it are scary theoretical and worry warts. So the documentation they write often goes way overboard and gets a little too technie. Having worked for an International bank, I can tell you firsthand that the theoretical and the practical are two very different things. Unless you're protecting billions in transactions as my previous employer was, it just doesn't need to be that insane.

Consider OpenID. It's really very easy to make work well.

bpeterson76
This is exactly the kind of answer I was _not_ looking for. How is MD5 hashing the username and password in JavaScript before sending to the server considered secure? OpenID isn't really aimed at corporate users. Just because I don't have billions of transactions doesn't mean my users data is any less important.
Joony