I've had the same question for a few years. Never bothered to ask or research though oh, so I'm glad to see that you asked and I'm eager to see what the consensus is.
Re:Peppering (Password Storage)
by GoblinSlayer on Friday July 03, 2020 @08:54AM
(#23723528)
It will have a performance tradeoff that you can spend on more iterations. The concern of extra data seems trivial, the output of bcrypt is already a serialized structure and should be easy to extend, and technically is not different from planned hash migration.
Let's say you have a secure password hash that includes a work factor, sph(pw, wf) (I'm going to ignore salt to simplify notation).
The most widely used ones such as PBKDF2, bcrypt, and scrypt do not include any good way to upgrade an existing hash to a bigger work factor.
The way that is usually handled is to flag passwords that are hashed with the smaller work factor and the next time the user logs on you can rehash the password with the new work factor.
I don't like that approach. If I'm raising the work factor it is presumably because I decided that the old one is not secure enough. I want to stop using it. I could just invalidate all the old passwords and make everyone go through password recovery, but that is not ideal.
Another approach could be to replace all the password hashes that use the old work factor, sph(pw, old_wf), with sph(sph(pw, old_wf), new_wf) and add a flag indicating that they are double hashed. Then update to sph(pw, new_wf) next time the user logs in.
I still don't like that. It does solve the problem of having insecure hashes while waiting for people to get around to logging in, but it still requires keeping some extra data around (a flag marking double hashed passwords--or worse if we have to deal with people who have gone more than one work factor upgrade without logging in).
What I'd really like is the password hash to be a pair of functions, sph() and sph_cont(), with the following property for integers 0 < wf1 < wf2:
With that, when I upgrade the work factor I can update all the hashed passwords to the new work factor.So...why aren't the common secure password hashes designed this way? Does it introduce some kind of unavoidable security issue?
Just looking at some of them from a computation point of view, not from a security point of view, it seems doable. The general structure is (1) do some setup, (2) do some look wf times, and (3) do some post processing. If the post processing were reversible so that you could get back to the state right after wf iterations then you could do additional iteration to increase the work factor.
Is there something that makes it so that the steps between the final iteration and the output must necessarily be irreversible in order for the whole thing to be secure?