Hacker News new | ask | show | jobs
by jacksingleton 3362 days ago
@AgentME -- correct

@franciscop -- keep an eye out for the rest of the article (it's already written and will be released soon). I go over the impacts of an attacker knowing the secret in much more detail. I also have sections on prevention for both application developers and library/framework authors that I think you'll find interesting!
1 comments
franciscop 3362 days ago
I'll wait for it, because I don't fully understand @AgentME's comment "to generate cookies that authenticate them as other users". Those auth cookies would have a hashed token per user that must be created and validated in the back-end (besides the encryption). So just storing 'user-ID' should not be enough, you'd have to be able to decrypt a real user's cookie to know this token hash (and for this reason just guessing numbers/users ID would not be enough as well).
link
AgentME 3362 days ago
The cookie that the user gets might be something like userid + ":" + HMAC(server secret, userid). The user who gets that cookie can brute-force HMAC(x, userid) with different values of x until they get a match for the string in their cookie, at which point they know the server secret. Then with the server secret, they can generate a valid cookie for any userid.
link
franciscop 3362 days ago
That is exactly what I mean, you are not supposed to save the user id (hashed, encrypted or otherwise) in the cookie. You are supposed to save a random secure token that will be associated to that user's device/login. If you save the user id it'd be as an index, not for auth as the token is for that. See http://stackoverflow.com/a/32218069/938236

Of course then it depends on the developer, so statistically speaking there will be a % who do what you suggested and making it secure from the library/framework side would help some users, so I'm all in for it.

link
AgentME 3361 days ago
That strategy is often called sessions or a stateful-cookie. It requires all of the servers that accept that cookie to be able to share their session state (or for a strategy like sticky sessions to be used). The strategy I described is stateless: the servers only need to share the secret in order to verify the cookie. It's a popular strategy but it does have some trade-offs, such as being vulnerable to anyone who knows the secret.
link
semantics 3362 days ago
Let's say your Python web application pickles your sessions so you can store more than just JSON serializable fields. Unpickling can result in the execution of arbitrary Python code and the only thing normally protecting you is that you MAC your session with the secret key (which was just cracked...)

I need to think on the user impersonation a bit.

link