[dendory]

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.

[sehrope]

> 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...

[danielweber]

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

[atburrow]

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.

[stouset]

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

[markdown]

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)

[unclebucknasty]

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?