[voycey]

The point of bcrypt though is that it is (more) future proof in that the hash generation is slow as balls and can be made exponentially slower by increasing the difficulty.

Other than some kind of algorithm weakness this slowness will translate through to the brute force attack thus taking longer for an attacker. BCrypt also has something that means it is harder for a GPU to crack it (mutable RAM memory tables or something).

As for migrating passwords - you can use a fallback password hasher that checks against a previous hash should the main one fail - then once the login is successful re-hash with the newest algorithm!

[Matt3o12_]

You can't really know how future proof it is, though. As far as I know, nobody has proven it to be unbreakable. Right know we can't break it, we can only brutal force it but maybe tomorrow a mathematician finds some properties to calculate all possible inputs of a certain length for the hash within a reasonable time. Or maybe they find another way that doesn't include brutal force (statistics, ...).

What I'm saying is that passwords are hard in general (to store, to enforce policies properly, ...) and just because bcrypt is "unbreakable" right now, doesn't mean it has to be in 5 years.

Your last paragraph describes nicely what needs to be done, but is your code ready for that? Maybe your database password/salt column only allows X characters, now you need to rebuild the database. Maybe something else expects the passwords to have that specific format (another micro service, some script, ...). Re-hashing a password can be hard if this possibility was not considered from day one.