3

It is my belief that passwords hashed using PHP's password_hash() function may be transferred to different systems and still be successfully used for verification purposes.

It's my understanding that the bcrypt hash contains all the necessary components that, when combined with the plain text password, the given password may be verified. Because of this, the hash can be taken to any system with a compatible implementation and used for verification purposes.

I will be trying this out soon, but before I do I would like to know if my theory is correct.

Is this correct?

kittycat
  • 14,983
  • 9
  • 55
  • 80
michaelward82
  • 4,706
  • 26
  • 40

4 Answers4

5

Yes, it is correct. The documentation for password_verify states:

Note that password_hash() returns the algorithm, cost and salt as part of the returned hash. Therefore, all information that's needed to verify the hash is included in it. This allows the verify function to verify the hash without needing separate storage for the salt or algorithm information.

Of course it's also easy to see that this information is there by inspecting the output of password_hash and crypt (which is, to overgeneralize a bit, mostly the same thing).

Jon
  • 428,835
  • 81
  • 738
  • 806
  • Thankyou for the link to the docs. I had read the password_hash() docs and didn't think of reading up on the password_verify() function – michaelward82 Sep 25 '13 at 13:18
2

Yes, crypt() based hashes are portable; they can be transferred to any system and they can be used to successfully verify a given password, because it contains all necessary data to perform this verification.

Note that a high cost factor may cause lesser systems to take longer to verify a password, due to the higher number of iterations required.

Also take care of the storage requirements; if you're always going to use bcrypt it's safe to store password hashes in varchar(60) columns. Otherwise varchar(255) is recommended.

Ja͢ck
  • 170,779
  • 38
  • 263
  • 309
  • I'm aware of the cost issue, but I'm glad you mentioned it. I have chosen to use binary(60) for storing the hash values - see http://stackoverflow.com/questions/5881169/storing-a-hashed-password-bcrypt-in-a-database-type-length-of-column – michaelward82 Sep 25 '13 at 15:38
  • @michaelward82 I typically use `latin1` collation on tables that don't store locale sensitive values, but `binary` will do just fine as well :) – Ja͢ck Sep 25 '13 at 23:20
1

The bcrypt algorythm includes it's own vector and/or salt and should be portable. Neither hash nor vecotor/salt include anything specific to a system.

This should also be applicable to any other algorythm that either doesnt use a vecotr (or other element in addition to the hash) or includes this hash in it's output.

ToBe
  • 2,667
  • 1
  • 18
  • 30
-2

I don't know where you wanna save the hash, but if you save it to database, usw the database own encryption/hash functions complain it

example (with encryption)

INSERT INTO table (pass_hash,....) VALUES ( MD2 | MD4 | MD5 | SHA | SHA1 | SHA2_256 | SHA2_512 (" $password ") )
SELECT * FROM table WHERE pass_hash = MD2 | MD4 | MD5 | SHA | SHA1 | SHA2_256 | SHA2_512 (" $password ")
timod
  • 585
  • 3
  • 13
  • We're already using the hashes. I need to know if there is any reason why I could not take the hash, store it elsewhere for another system, and still expect the hash to validate. I can't see the relevance of this answer. – michaelward82 Sep 25 '13 at 13:15