RE: [PHP] Re: crypt()
You should give some consideration to _not_ emailing passwords. Many popular sites rely on double entry of a password during registration which reduces the need to email the password to the user during confirmation of their registration. The fact that most users have only 1 password which they use for /every/ registration process would make that email even more redundant (and quite a large security risk for the user!). The lost password procedure could just involve emailing the user a 'reset password' link (perhaps even after asking for a mother's maiden name or similar). IMHO this gives a very good security/ease-of-use trade-off. -- ___ | | |--+-- | |.HushFriend (you'll see). .Stefan Holmes. -Original Message- From: Ian Firla [mailto:[EMAIL PROTECTED] Sent: 26 August 2004 14:25 To: Aaron Todd Cc: [EMAIL PROTECTED] Subject: Re: [PHP] Re: crypt() On Thu, 2004-08-26 at 15:01, Aaron Todd wrote: Thanks for the tip, it worked great, however everything I have been reading says that md5 is only one way. The way I have setup my app is the database contains the encrypted version of what the user entered as their password. Then on my login page there is an if statement that encrypts what the user is entering as their password and then checking that against what is in the database for them. This is working great!...Thanks again. My registration page is where the password gets encrypted and then sent to the database. After the user registers and I accept them as a user they recieve an email containing their username and password. But the password is encrypted. Is there a way to decrypt the encrypted password in the database? Or am I going about this wrong? Send the password before it gets encrypted and put into the database. You can't decrypt an md5 encrypted password. Ian -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: crypt()
you can use md5() which will create an encrypted string that cannot be encrypted, or you can use something like base64_encode() which has the inverse base64_decode, 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 -- -- Jasper Howard :: Database Administration Velocity7 1.530.470.9292 http://www.Velocity7.com/ -- Aaron Todd [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I have developed a PHP based site that requires users to login. Their login information is kept in a MYSQL database. Currently, I am using an IF statement to verify what the user enters as their password with what is in the the database. If they are the same a session is created and they have access to the content of the site. As far as I know the password is being sent to the script in clear text and I was wondering what a good way would be to get this to be encrypted. My first thought is to encrypt the password in the database using crypt(). So if I view the table I will see the encrypted characters. Then change the IF statement to encrypt the password that the user enters and then just check if its the same as what is in the database. That sounds like the same as I am doing now only instead of checking a password that is a name, its checking the encrypted characters of the name. So it seems my idea would hide the real characters. Can anyone tell me if this is a bad idea. And maybe point me toward a good one. Thanks, Aaron -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: crypt()
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
[PHP] Re: crypt()
good to know -- -- Jasper Howard :: Database Administration Velocity7 1.530.470.9292 http://www.Velocity7.com/ -- M. Sokolewicz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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
[PHP] Re: crypt()
Aaron Todd [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I have developed a PHP based site that requires users to login. Their login information is kept in a MYSQL database. Currently, I am using an IF statement to verify what the user enters as their password with what is in the the database. If they are the same a session is created and they have access to the content of the site. As far as I know the password is being sent to the script in clear text and I was wondering what a good way would be to get this to be encrypted. My first thought is to encrypt the password in the database using crypt(). So if I view the table I will see the encrypted characters. Then change the IF statement to encrypt the password that the user enters and then just check if its the same as what is in the database. That sounds like the same as I am doing now only instead of checking a password that is a name, its checking the encrypted characters of the name. So it seems my idea would hide the real characters. Can anyone tell me if this is a bad idea. And maybe point me toward a good one. Thanks, Aaron Hi Aaron, encrypting passwords in the database is generally a good idea. You can use md5() as an alternative to crypt(). MySQL itself has an MD5 function you can directly use in your SQL statements. Regards, Torsten Roehr -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: crypt()
Thanks for the tip, it worked great, however everything I have been reading says that md5 is only one way. The way I have setup my app is the database contains the encrypted version of what the user entered as their password. Then on my login page there is an if statement that encrypts what the user is entering as their password and then checking that against what is in the database for them. This is working great!...Thanks again. My registration page is where the password gets encrypted and then sent to the database. After the user registers and I accept them as a user they recieve an email containing their username and password. But the password is encrypted. Is there a way to decrypt the encrypted password in the database? Or am I going about this wrong? Thanks again for your help. Aaron Torsten Roehr [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Aaron Todd [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I have developed a PHP based site that requires users to login. Their login information is kept in a MYSQL database. Currently, I am using an IF statement to verify what the user enters as their password with what is in the the database. If they are the same a session is created and they have access to the content of the site. As far as I know the password is being sent to the script in clear text and I was wondering what a good way would be to get this to be encrypted. My first thought is to encrypt the password in the database using crypt(). So if I view the table I will see the encrypted characters. Then change the IF statement to encrypt the password that the user enters and then just check if its the same as what is in the database. That sounds like the same as I am doing now only instead of checking a password that is a name, its checking the encrypted characters of the name. So it seems my idea would hide the real characters. Can anyone tell me if this is a bad idea. And maybe point me toward a good one. Thanks, Aaron Hi Aaron, encrypting passwords in the database is generally a good idea. You can use md5() as an alternative to crypt(). MySQL itself has an MD5 function you can directly use in your SQL statements. Regards, Torsten Roehr -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: crypt()
On Thu, 2004-08-26 at 15:01, Aaron Todd wrote: Thanks for the tip, it worked great, however everything I have been reading says that md5 is only one way. The way I have setup my app is the database contains the encrypted version of what the user entered as their password. Then on my login page there is an if statement that encrypts what the user is entering as their password and then checking that against what is in the database for them. This is working great!...Thanks again. My registration page is where the password gets encrypted and then sent to the database. After the user registers and I accept them as a user they recieve an email containing their username and password. But the password is encrypted. Is there a way to decrypt the encrypted password in the database? Or am I going about this wrong? Send the password before it gets encrypted and put into the database. You can't decrypt an md5 encrypted password. Ian -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: crypt()
Hello
'salt' basically is the initialization sequence for the encryption. This
makes the function use more random numbers since the salt will be
different on different calls. At least it should be
So in order for your crypt() to work you have to pass the same salt to
both functions.
To determine the 'salt' take the first two letters/numbers (this is the
defualt but better check the PHP constant CRYPT_SALT_LENGTH for the real
length of the salt) of the crypted text and pass them as the salt to the
second and they should come out equal...
?PHP
$test=crypt('test');
print $test. br;
$test2=crypt('test', substr($test, 0, 2)); // if CRYPT_SALT_LENGTH is
more then two just pass in that number as the
// third parameter to substr
print $test2. br;
?
Have fun experimenting around
Stefan
