3 ms·
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
by dendory 13y ago
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.
- atburrow 13y agoWhat 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.
- stouset 13y agoNo. None of these. Please stop. The system is entirely broken. No amount of tweaking is going to fix it.
- sehrope 13y ago> 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_authentication_code http://en.m.wikipedia.org/wiki/Hash-based_message_authentica...
- danielweber 13y agoI have two ISPs at home. What happens when the next day my router decides to use the other IP address?
- markdown 13y agoIn 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)
- unclebucknasty 13y agoI'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?