Well, all passwords on my sites are stored md5'd, so i'm comparing an md5() of the password they have supplied with the one stored in the DB, so I don't need to know what the original password was -- only if the two encrypted passwords match.
Since md5() is one-way encryption, it makes sense to store the password in a cookie this way as well, so that people digging around can't possibly figure it out. I guess leaving the password in plain text in the cookie opens a small security hole which is unneccassary, as long as you're storing an encrypted password in the database. Justin French on 15/06/02 7:51 PM, Leif K-Brooks ([EMAIL PROTECTED]) wrote: > I'm currently storing the username and password directly in cookies (the > password isn't even md5()'d). I'm just wondering if there's security > risks/whatever in sessions. I've seen that most sites seem to store the > login data directly in the cookie (with the password md5()'d). Is that > because there's something wrong with sessions, or did they just not use > them for no reason? Thanks. > > Justin French wrote: > >> How is it currently storing it? >> >> Sessions are fine, depending on how the code is written, and the obviouse >> downside to COOKIE based sessions is that they will break on non-cookie >> browsers, so a smarter move is to use URL based sessions. >> >> A more focused question will of course result in a more focused answer :) >> >> Justin French >> >> >> on 15/06/02 6:59 PM, Leif K-Brooks ([EMAIL PROTECTED]) wrote: >> >> >> >>> I am planning to change how my site stores logins to using sessions. >>> Are there any reasons not to do this? Reasons against it I should >>> know? Thanks for your input. >>> >>> >>> >> >> >> >> > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
