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


-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php



Reply via email to