Re: crypt()

good to know -- -------------------------------------------------------------->> Jasper Howard :: Database Administration Velocity7 1.530.470.9292 http://www.Velocity7.com/ <<-------------------------------------------------------------- "M. Sokolewicz" <tularis@php.net> wrote in message news:20040827174043.16552.qmail@pb1.pair.com... > Jasper Howard wrote: > > you can use md5() which will create an encrypted string > that's not entirely true, all it will do is compute the md5-hash of that > string. Which is *always* a 32-character hexadecimal number (though > before PHP5.0.0 it was returned in a different way). The big difference > between a hash and an encypted string is the fact that a hash does NOT > store the string it was computed of. This means that there are more than > 1 possible strings for the same hash. While an encrypted string *always* > has only 1 single possible "result" when decrypted (with the right keys, > etc. etc.). > > For storing passwords in a database you can easily use md5, although > this means that you don't store the actual password (you store the > HASH), and the user could, in theory, send a completely different string > and still gain access to the account. This is not easy however. MD5 is > very well known for the fact that a very small change in the initial > string makes for a big change in the resulting hash. It's basically > infeasible to actually (reverse-)compute a possible initial string which > results in the same md5-hash. So basically for storing passwords, it's > safe enough. Remember though that you're not storing the password > itself! So you'll never be able to get the actual password to check > against. You'll need to compute the md5-hash of the provided password > and THEN check that against the stored hash. > > Back to encrypted strings. Encryption is very complex, and can *always* > be reverse-engineered. Although it's (in most cases) infeasible to do, > it is theoretically possible for all encrypted strings. Another thing to > remember is that longer unencrypted strings also make longer encrypted > strings. This is because the data inside *CAN* not be lost. > > So, a quick overview of both: > Hashes: fixed-length, but not recoverable > Encrypted: variable-length, but recoverable (with a key) > > You'll need to carefully choose between those two. Also please remember > that it is always most efficient to keep a fixed-length string in a > database than a variable-length one. > > > that cannot be > > encrypted, or you can use something like base64_encode() which has the > > inverse base64_decode, > base64 is not an encryption. It is an en*coding*. This means that if > someone knows it's 'base 64', that person will always be able to decode > it, no matter what. Base64-encoding in particular was created to be able > to (safely) send binary data trough non 8-bit-clean layers. > that way you have an encrypted string in the database > > but if for example a user loses their password, instead of setting a new > > one, you can retrieve the old one. This of course won't be as secure, but > > anyone that gains access to your db will not be looking at the real password > > and will have to know to decrypt it using base64_decode(). > > > > hope that's informational, > > -ApexEleven > >