What would happen is that newly-hashed passwords will be using the new algorithm - obviously.
However, you shouldn't be concerned about this, because the whole thing is designed with forward-compatibility in mind - your code won't be broken when the default algorithm changes, as long as you're using the password_*()
functions correctly.
By correctly, I mean use password_verify()
.
password_verify()
accepts a plain-text password and a hash, and it can easily determine what the used algorithm is by looking at the hash that you feed it. Therefore, it would also still be able to verify a password that has been hashed using an old algorithm - not just the previous one, but any algorithm that is supported.
In fact, the sole purpose of the PASSWORD_DEFAULT
constant is that you can easily migrate older hashes to a new algorithm (once one is added). This happens the following way:
- When a user logs in, you verify their password via
password_verify()
(any hashing algorithm that has a PASSWORD_<name>
constant will work).
- You call
password_needs_rehash()
, and if the password you just verified is using an older algorithm (or a lower 'cost' paramater) - it will return boolean TRUE.
- If boolean TRUE was indeed returned, you can now replace the old hash with one that uses the new algorithm; you can do that during a login, because the user just gave you the password and you verified that it is correct.
In summary - it's a really, really well-designed API and it solves problems for you that you haven't even thought about. Don't worry about it.
Edit (noted in the comments):
It should be noted, however, that new algorithms will quite probly result in longer hash lengths, so if you're storing the passwords in a database - don't limit the field's length (i.e. use a varchar(255)
field).