Hacker News Reader

Comment by UnoriginalGuy | Hacker News Reader

I'm normally highly sceptical of anything which is essentially a how to guide on security of, well, anything but I have to say whoever this author is they absolutely know their stuff.

Normally security advice is just 1980s circle-jerking of the same meaningless "sound good" concepts (e.g. "At least one upper-case, number, special character") but actually, no, not in this case.

Instead he is giving advice which is modern, which is based on how people actually use these systems, and also the common mistakes developers make while building them (e.g. not hashing forgotten password keys).

He even linked to NIST Special Publication 800-63 and THEN talked about login attempts over time. This dude is just incredible. I literally couldn't have written a better article than this.

View on HN

To provide a counterpoint, the section about the "Remember Me"-cookie is rather terrible (I stopped reading after that).

It's not fundamentally flawed but rather inelegant (and potentially expensive) to store a magic number server-side for each session. You can implement the same thing more easily by handing out tamper-proof (HMAC) cookies containing the start- and end-time, and storing only the last_logout-timestamp for each user on the server-side.

Any cookie where expire_at < now or created_at < last_logout is to be rejected at validation time.

The problem for most mere mortals with the HMAC scheme is that there is a very real possibility of the server being compromised and the secret key being stolen. In this case an adversary could generate valid cookies for any user. However, with the magic number scheme as long as only the hash of the random number is stored (we should add a per-user salt too) then the entire session database could be compromised, but an attacker cannot do anything with it.

Also, though less of an issue with SSL, the HMAC approach is subject to replay attacks while expire_at < now.

EDIT: The HMAC approach also lacks any method to invalidate cookies manually, or automatically e.g. when the user changes their password. This means a compromised account is open to attack until expire_at < now, and there's nothing you can do about it other than blocking the account for that duration, which now means that each request needs to do a database lookup to see if the account is blocked. You could generate a per-user secret key, but now you have a database lookup again, so you might as well use the magic number scheme.

If your server is compromised you tend to have bigger problems than session forgery. Why would an attacker bother to fabricate http-sessions after he already gained access to your database and, in most cases, source-code?

Replay-attacks work the exact same whether you use this scheme or store a magic number server-side. There's no difference whatsoever.

For a password-change you update the last_logout timestamp and hand the user a new cookie (since his current one was just invalidated).

I think that is the beauty to this post it wasn't one person... However, Jeff Atwood seems to be the main contributor. He was also the co-founder of Stack Overflow.

http://stackoverflow.com/posts/477578/revisions

The power of team work.

He's probably incorporating information from highly rated posts below, rather than generating content.

That's what he says he did in the related meta post: http://meta.stackoverflow.com/questions/95172/old-problemati...

Reply on news.ycombinator.com