in reply to Re: Is this use of crypt() appropriate?
in thread Is this use of crypt() appropriate?

Creating a session ID is simple, and probably better than worrying about how to encrypt a password and decrypt it reliably. If you have the MD5 module available, why not just hash the password against the time (or using crypt you could salt the password or the userid with the last two digits of time() or a random key and send this back in the cookie-- you then store this session ID in a field in the DB and do a simple compare each time. For storing the session ID you could go the extra step of using the MySQL crypt() function to keep people with DB access from easily reading it there.

As I said before, if I can intercept the transmission of the cookie I can spoof all day long unless you also include an IP check (and I might be able to spoof IP too, just not as easily) or auto-expire.

As was pointed out, the most vulnerable area is going to the dictionary crack, since it relies on the strength of the user passwords themselves (and users are notorious for choosing poor passwords). All that is required to execute a dictionary crack is a script that emulates the input from your login form and runs through the dictionary trying sensible combinations of words, etc etc. So I wouldn't worry too much about what's in your cookies except that it not easily reveal the password itself and that it not be easily predicted.
  • Comment on (ichimunki): Is this use of crypt() appropriate?