Re:One Line of Code That Compromises Your Server
by AgentME on Saturday April 01, 2017 @07:14PM
(#14014711)
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.
[ Parent
| on HN ]
Re:One Line of Code That Compromises Your Server
by franciscop on Sunday April 02, 2017 @08:33AM
(#14016913)
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.
Re:One Line of Code That Compromises Your Server
by AgentME on Sunday April 02, 2017 @03:41PM
(#14018645)
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.