Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Multipassword or multicrypt? #37
Prior art: MCF (Modular Crypt Format).
You've probably seen them around:
This isn't a formal protocol proposal. I'm not quite sure whether this would be useful under the umbrella of multiformats, or given that MCF already exists and is fairly well-used. However, I have put this together:
This multiformat would provide a binary, machine-readable, centrally-defined format for password hashes. Modern password hashing has typically three parameters: the algorithm used, the salt employed, and the strength factor of the hash (usually in number of rounds).
Being able to support multiple password hash formats is important as security requirements progress. This is less an interoperability problem like multihash or multikey where the data would be used between different programs, and more an application-lifetime problem where the data would be used typically by the one program, needing to support multiple concurrent password hashing schemes as transitions occur (sometimes spanning months or years, as the new format can only be applied when the original password is available, i.e. when a user logs in).
The format might be like:
Something that may not be optimal in this design is there is no indication of overall length, so it cannot be easily skipped over. Usually such data would be stored in a database so the concern may not be justified, but it could still be resolved.
One problem with MCF is the lack of agreed-upon algorithm list, another is the lack of formal definition of parameters. MCF is technically a two-field format:
For compatibility, this multiformat may wish to define an MCF prefix, e.g.
It's an adjustable "cost" that most modern password hashing schemes have. Usually translates to the number of rounds. You adjust it based on current or projected attack power, and based on how long a hash at that strength takes on your servers.
For example Bcrypt's is a small integer which directly translates to the number of rounds as a power of two. The current recommended value for Bcrypt is 12, that is, 2^12 rounds. On my servers, it takes ~300ms to compute a single hash, which is a good enough trade-off for usability.
You have to carry it around simply because it's one of the inputs of the hashing function. You can't verify the hash without it.
Ah of course.. see I was getting confused that the MCF example you gave didn't carry a strength factor but after looking closer I realized you say:
But for bcrypt (your example in particular) it is actually:
where salt is 22 chars. Yes, MCF has issues. I really like this idea.