Multihash doesn't work for storing password hashes, both because the cryptographic hash algorithm are too fast for password hashing, and because password hashes need extra info like the salt and parameters like the work factor for Bcrypt.

There are two standardized formats that can be used for storing password hashes in one field. There is the RFC2307 format from LDAP which prefixes the algorithm like "{MD5}". There is also the crypt format which uses prefixes like "$1$".

There isn't a standard RFC2307 scheme for Bcrypt but can use "{CRYPT}" for crypt format, or "{BCRYPT}" with crypt-style bcrypt hash.

That's why one of my options is a custom hash algorithm table; Multihash has explicit support for using your own hash functions. AFAIK part of the implementation of custom hash function table entry in Multihash is a protocol to encode metadata alongside the hash, e.g. by appending the salt to the hash, perhaps separated by some special character (e.g. base64 encoded hash + ":" + base64 encoded salt). This is not part of the table, so maybe that would make it inconvenient to use. I haven't read enough of the code to know.

I do think it would be much nicer to have this in the Multihash library itself. Easy hash function migration is a great feature to have when you have to store user passwords.

I also find standardized text-based formats for storing multiple types of hashes in one field interesting, but I'm not sure if it's worth the effort to implement myself vs. extending Multihash. I like that Multihash encapsulates the parsing logic and that it has libraries in many languages, so I can easily interact with the DB entries from e.g. scripts or new codebases.

I think the cool thing about Multihash is the very broad platform support, the small scope, the convenient API to interact with a DB + hash function table, and the default function table; I'd only be missing out on the default function table if I were to use a custom function table.

Multihash table doesn't contain those functions but this doesn't mean that you can't change it. You can open an issue and thus start discussion about it. I am sure that it will be accepted in some form.

It also explicitly supports using your own hash function table, but I agree it'd be useful to have password-storage suitable hash functions included in the defaults.

You might want to take a look at how Django does it, which is more or less an accepted best practice. https://docs.djangoproject.com/en/1.10/topics/auth/passwords...