Creating and Verifying Hashes in PHP 5.5 • Hacker News Board

Re: Creating and Verifying Hashes in PHP 5.5

#31

Post by byroot » Fri, Jun 21, 2013, 4:34 PM UTC

pilif wrote: post #29

Achshar wrote: post #27

Earlier quoted context omitted.

I am on md5 on one of my projects but it's salted alright. I want to change it. I reckon there is no way to migrate other than resetting every user password.

You could add a second password column to your users. Then if that column is empty, authenticate against the old password. If it passes, hash the password (just supplied by the user) with bcrypt and store it in the new column. Over time, active users get their password upgraded. Then after a longer time, just reset the passwords of the users who never logged in since you started migrating.

You can even do simpler.

On signup store:

  $password = password_hash(md5($password),PASSWORD_BCRYPT);

And on login:

  password_verify(md5($password), $password_hash);

Then you just have apply password_hash() on all you passwords in database.

Bonus the migration is instantaneous, you don't need a 6 month transition period.

IMHO it do not reduce the security, but i'm not a crypto expert though.

Re: Creating and Verifying Hashes in PHP 5.5

#32

Post by maratd » Fri, Jun 21, 2013, 4:35 PM UTC

bpatrianakos wrote: post #5

This is a great addition to PHP. Before, most new devs would either skip hashing passwords altogether or use `md5()` or `sha1()`. So you'd end up with databases with passwords in plaintext or easily cracked. Bcrypt frameworks for PHP were too confusing for beginners. If you were lucky you were using a framework that took care of hashing and salting passwords and if you were extremely lucky you had bcrypt available on…

> There do exist experienced PHP devs who would do password storage the right way but PHP up until now neither made it easy nor encourage these practices as they relate to passwords.

As much as I welcome these features, I don't think that's true. PHP has made it extremely easy to use the core operating system's hashing features.

http://us3.php.net/manual/en/function.crypt.php

And after 5.3, even if for whatever reason your operating system is lacking, they were built in for convenience.

Re: Creating and Verifying Hashes in PHP 5.5

#33

Post by Jeremy1026 » Fri, Jun 21, 2013, 4:35 PM UTC

DoubleMalt wrote: post #30

Jeremy1026 wrote: post #28

Earlier quoted context omitted.

Actually, you can migrate slowly. Create a second password column on your database to store your new hash. When a user logs in check if the new column is blank. If it is check that they entered the password correctly by verifying against your MD5 hash. If it is correct rehash their plain text and store it in the new column. If the new column isn't blank, then the have already logged in and you have the new hash, so v…

Don't forget to delete the value in the md5 column, otherwise the whole exercise is for naught.

Correct.

Re: Creating and Verifying Hashes in PHP 5.5

#34

Post by workhere-io » Fri, Jun 21, 2013, 4:36 PM UTC

It certainly makes handling passwords easier. Another option, though, would be to use Persona, in which case you don't store passwords at all.

Re: Creating and Verifying Hashes in PHP 5.5

#35

Post by Jeremy1026 » Fri, Jun 21, 2013, 4:40 PM UTC

byroot wrote: post #31

pilif wrote: post #29

Earlier quoted context omitted.

You could add a second password column to your users. Then if that column is empty, authenticate against the old password. If it passes, hash the password (just supplied by the user) with bcrypt and store it in the new column. Over time, active users get their password upgraded. Then after a longer time, just reset the passwords of the users who never logged in since you started migrating.

You can even do simpler. On signup store: $password = password_hash(md5($password),PASSWORD_BCRYPT); And on login: password_verify(md5($password), $password_hash); Then you just have apply password_hash() on all you passwords in database. Bonus the migration is instantaneous, you don't need a 6 month transition period. IMHO it do not reduce the security, but i'm not a crypto expert though.

It does add extra computational power to your log in though. While it is a minimal amount, depending on the size of your application it could be notable.

Re: Creating and Verifying Hashes in PHP 5.5

#36

Post by nikic » Fri, Jun 21, 2013, 4:43 PM UTC

maratd wrote: post #32

bpatrianakos wrote: post #5

This is a great addition to PHP. Before, most new devs would either skip hashing passwords altogether or use `md5()` or `sha1()`. So you'd end up with databases with passwords in plaintext or easily cracked. Bcrypt frameworks for PHP were too confusing for beginners. If you were lucky you were using a framework that took care of hashing and salting passwords and if you were extremely lucky you had bcrypt available on…

> There do exist experienced PHP devs who would do password storage the right way but PHP up until now neither made it easy nor encourage these practices as they relate to passwords. As much as I welcome these features, I don't think that's true. PHP has made it extremely easy to use the core operating system's hashing features. http://us3.php.net/manual/en/function.crypt.php And after 5.3, even if for whatever reaso…

crypt() is not extremely easy to use. Actually, it's fairly hard and easy to get wrong. The two things that people usually get wrong is a) salt generation and b) fixed-time comparison.

Re: Creating and Verifying Hashes in PHP 5.5

#37

Post by LeafStorm » Fri, Jun 21, 2013, 4:46 PM UTC

maratd wrote: post #32

bpatrianakos wrote: post #5

This is a great addition to PHP. Before, most new devs would either skip hashing passwords altogether or use `md5()` or `sha1()`. So you'd end up with databases with passwords in plaintext or easily cracked. Bcrypt frameworks for PHP were too confusing for beginners. If you were lucky you were using a framework that took care of hashing and salting passwords and if you were extremely lucky you had bcrypt available on…

> There do exist experienced PHP devs who would do password storage the right way but PHP up until now neither made it easy nor encourage these practices as they relate to passwords. As much as I welcome these features, I don't think that's true. PHP has made it extremely easy to use the core operating system's hashing features. http://us3.php.net/manual/en/function.crypt.php And after 5.3, even if for whatever reaso…

Except generating a random salt and the proper hash format to provide as input to crypt() is surprisingly difficult, especially in a cross-platform way. I recently replaced my custom crypt wrapper with the userland implementation of these functions, and in the process I discovered my custom wrapper had some rather non-obvious bugs.

Re: Creating and Verifying Hashes in PHP 5.5

#38

Post by mikeryan » Fri, Jun 21, 2013, 4:46 PM UTC

baby wrote: post #17

Can someone explain to me what the "cost" option is?

One reason why Bcrypt has taken over for other hashing algorithms is because it introduces a "work" factor which allows you to extend the amount of time it takes to calculate the hash in order to prevent brute force attacks. By making the work factor or "cost" adjustable you get some protection against Moore's law because as computers get faster you can up the "cost".

Canonical article on why bcrypt which explains it here

http://codahale.com/how-to-safely-store-a-password/

Re: Creating and Verifying Hashes in PHP 5.5

#39

Post by ircmaxell » Fri, Jun 21, 2013, 4:55 PM UTC

nly wrote: post #20

showerst wrote: post #8

Just noting if you're new to this you don't have to add a salt, by default password_hash with bcrypt will add a random one to each password.

Assuming the RNG isn't duff, which PHP has stumbled on a few times in the past, with session keys and such.

Check it out for yourself. Here's the random generating parts, pulled out for you: http://stackoverflow.com/questions/14673005/how-does-phps-pa...

Re: Creating and Verifying Hashes in PHP 5.5

#40

Post by cryptbe » Fri, Jun 21, 2013, 5:00 PM UTC

If the password hashing APIs asks developers to generate a salt on their own it's neither easy nor safe.

I've worked on password hashing recently, and I think the best interfaces should take only a password, and return a hash. Modern password hashing algorithms, e.g., bcrypt, scrypt, etc., usually also need a set of local parameters. The API should hide them as well, and expose only a set of interfaces with safe and sound preconfigured parameters, which in turn determine how much CPU time and memory space will be used. One disadvantage of this approach is that it exposes the local parameters, hence make it a little bit easier for attackers.

This is exactly how crypto primitives have been designed. If the designers of AES ever let people choose the key size, sooner or later some people would shoot themselves in the foot, and set the key size to 1-bit. If you think this is an extreme example, it actually has happened, not in some obscure API that nobody uses, but in the very XMLDsig standard published by W3C [1].

Regarding password hashing standards, I found many misuses of libscrypt that would make it extremely easy to recover passwords. But I'll save the details for another blog post or something.

[1] http://www.w3.org/QA/2009/07/hmac_truncation_in_xml_signatu....