Re: Is this use of crypt() appropriate?

Replies are listed 'Best First'.
Re: Re: Is this use of crypt() appropriate? by Anonymous Monk on Nov 08, 2001 at 14:28 UTC
Sorry to post twice, re-reading all the above posts, the use of a random salt does sound easier to implement..how would I use a 'salt' when encryptin a password ? simply by replacing '01' with '$salt' ? Thanks	[reply]
(ichimunki): Is this use of crypt() appropriate? by ichimunki (Priest) on Nov 08, 2001 at 21:02 UTC
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.	[reply]
Re: Re: Is this use of crypt() appropriate? by nufsaid (Beadle) on Nov 09, 2001 at 04:02 UTC
There is an alternative to random session keys which also avoids cookies (for those who don't like cookies): Have the user log in once with username and password and generate a long random string to use as the session key. Record the user, ip, current time, and session key in a database of active sessions. All URL requests for web pages, scripts, must be preceeded by the session key: http://yoursite.com/get.cgi?bdjaiwmcvndjqidm+the_page.html Everytime a page is requested, you check the session key, ip, and the current time against those in the database of active sessions. If the match fails, or the current time is longer than the lifespan you have chosen for the key, you request that the user log in. Using this approach, the password is only transmitted once, at the start of each session, and the session key is of limited use if it is intercepted because it has a short lifespan and must match with the ip. Note: The user never has to type in the key themselves, because you serve them up pages with the key already included in the links. This is not a major security problem for the reasons stated above. Joe.	[reply]