Hacker News Reader

Comment by dendory | Hacker News Reader

I tend to like doing: sha256(sha256($password) . $ip)

This encrypts the password and makes the cookie only usable by the IP it was set for. Then to verify the cookie, since I already store sha256 of the password, it's trivial to do, without having to store an additional token for persistence. Of course you can replace sha256 with your fav hashing function.

View on HN

> since I already store sha256

Storing SHA-256 of passwords is a bad idea. You should use either scrypt, bcrypt, or at the very least PBDKF2 (with a large number of rounds).

For a signed token round tripped to the client you should use an HMAC[1].

[1]: http://en.m.wikipedia.org/wiki/Hash-based_message_authentica...

I have two ISPs at home. What happens when the next day my router decides to use the other IP address?

What if the user gets their session hijacked when they're on a static or long-term dynamic IP? If the user were to relogin, their session ID would be the same. I think it would be beneficial to at least store a salt associated with their session and regenerate the salt when authenticating.

sha256($password . $ip . $random_salt)

You could also regenerate the salt periodically.

No. None of these. Please stop. The system is entirely broken. No amount of tweaking is going to fix it.

In most parts of the world, users have dynamic IP's that change every time they connect to their ISP (often multiple times/day in the case of home users)

I'm not sure why you'd ever want to put something password-derived in a cookie--even if its sha256'd 8 dozen times, then scrypted, etc.

There's just no value in using the password as a basis. Why not instead just generate a random, unique token?

Reply on news.ycombinator.com