How to compare password to encrypted password?
I have been working on a website, (one of my first) and I have ran into a problem with the passwords. I found the below code to encrypt a password, which is what gets stored in the data base. I assumed that when the user enters his or her username and password, I could simply grab the password, do the same thing with it, compare that with what is in the database and it would be the same encrypted string, but it is not.
How can I do this? I don't have to use the code below to encrypt the password. I am sure there are many ways.
$cost = 10;
$salt = strtr(base64_encode(mcrypt_create_iv(16, MCRYPT_DEV_URANDOM)), '+', '.');
$salt = sprintf("$2a$%02d$", $cost) . $salt;
$password = crypt($password, $salt);
I think you'll need to store the salt in the DB, too. Otherwise with that code the salt will be randomly generated each time, which will then cause the encryption results to be different.
That makes perfect sense after you pointed it out. I didn't think about the MCRYPT_DEV_URANDOM part of the algorithm.
Is there a better way to do that? It seems that storing the salt would make it much easier for someone to crack the passwords if they get access to the database. Not that I am storing anything that is sensitive but I would like to do it right.
personally i don't use a set salt or "random salt" instead I use a row that holds unchangeable data (such as signup date) of the user signup and use 128 bit encryption with the whirlpool algorithm.
by using an arbitrary row from the database any hack attempt that get hold of you password would not know what the salt key would be.
$salt = strtotime(date('Y-m-d h:i:s')); //the users signup date taken from database
$password = hash('whirlpool', $salt.'users desired password'); // this will give you a 128 character long hashed password.
The main purpose of using a salt is so that a cracker cannot simply use a pre-generated "rainbow table" of hashed passwords to search against with the hashed values in your DB. By using a different salt on each password, they would now have to regenerate a new rainbow table for each such salt - and do it twice if they have to guess whether it's being added to the beginning or the end. The best security practice is still to get/force the users to use very strong passwords. ("E5-tc!2_xM34-" is not going to appear in many rainbow tables. )
Another decent option. It's all about defense in layers: the more hoops you make a cracker jump through, the more likely it is he'll look for easier pickings -- unless you have "heroin content" that he just has to have.
Originally Posted by unasAquila
This whole area is very difficult to implement correctly without having a very good understanding of cryptography. I recently wrote a user management area in PHP and when I started researching this properly, I came to the conclusion that implementing this is not that straightforward.
The solution I ended up with is Openwall's Portable PHP Password Hashing Framework. This is e.g. what Wordpress (and many other projects) use for storing passwords, and makes the job very easy. Personally I would highly recommend anyone to use this instead of trying to come up with your own solution using PHP's encryption functions, because unless you have a very, very good understanding of encryption in this context, it's easy to get the implementation wrong.
Since PHP 5.5, there are built-in password hashing functions that do things the right way. And if you're not on 5.5, then you can use this forward compatibility library.
This is probably your best option right now.
I hadn't hear about that, that's an excellent move by PHP, sorely needed.
Originally Posted by Jeff Mott
Hmm, personally I think I'll still keep using Openwall's Portable PHP Password Hashing Framework for a while though, since it's mature. I'll wait until PHP 5.5 is more widely used and further stabalised and then start using the new built in functions for new projects, as they are definitely the way to go ultimately.
That is a great solution. Thanks!
Originally Posted by Jeff Mott
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)