Because he didn't have the password, he had a hash of the password.

So if the auth system wouldn't have let him login directly with the hash by changing his cookie, he wouldn't have been able to login as an admin.

Am I right to say this would've been easily prevented by putting the hash(salt + password + client IP) in the cookie, instead of just hash(password)?

Normally, if I understand right, the point of hashed passwords, is what is sent from client to server to auth is the ACTUAL password.

Then the actual password is hashed, and the hash of the input password is compared to the previously stored hash, to see if it matches.

This way, you need the actual password to auth, but the actual password is stored nowhere by the app, only the hash is -- so the actual password can't be stolen by getting access to the db or the file system or anything else, because it's simply not there. But it's what you need to auth.

This is really the whole point of storing hashes rather than original passwords. Right?

Now, I guess that would mean you'd store the _actual_ password in the cookie. But that does sound risky, even if the cookies are https only. Which is why usually you store a _session id_ in the cookie, and auth the session with a single auth action, not store the password in a cookie.

If I could upvote you multiple times I would. I see a lot of confusion on this matter, even on HN.

When authenticating, the server needs to do a hashing step to compare against the password database. Otherwise, it isn't a hashed password database - it's a plaintext password database.

The cookie should not contain something computable at all. It should be some kind of session identifier, generated by your code when user:pass combo checks out.

And if possible, store the session information somewhere else than your database. Redis and Memcached is a nice fit for stuff like that.

Well, the cookie should not contain anything computable by the user. You could use an encrypted cookie to store session information to save a round-trip to the DB. In that case it should be impossible for the user to derive the key or modify without detection (so HMAC-SHA256, GCM, Poly1305 or whatever authentication mode is fashinable/applicable.)

Using client IP is a bad idea - that can change quite frequently for some users.

My proposed solution only ties the cookie to the IP, so the user will have to login again if their IP changes. But this means that even if an attacker who doesn't know the password gets a cookie, unless they have the same IP they wouldn't get access.

What about people who are behind a proxy cluster, so each separate HTTP request may originate from a different IP address?

Assume nothing.