password hashing v2

[slingamn]

Just so we don't forget about it.

[DanielOaks]

bf04dc2 should do this in a sensible way, also upgrading users to use the v2 hashing silently. The main issue I'm having is with the serialCacheUpdateMutex mutex and whether I need to use it at all in the database update function -- could you confirm whether or not it's necessary? If it's unnecessary I'll rip it out wholesale.

Thanks for noticing this bug by the way, big derp on my end and misunderstanding of bcrypt in general. After this, I'll look at doing similarly with the passwords from config files, and remove the server-wide salt init for those.

edit: Hope you're having a great Easter, by the way! :D

[slingamn]

Interesting suggestion here:

https://blogs.dropbox.com/tech/2016/09/how-dropbox-securely-stores-your-passwords/

to use a first pass of SHA-512 before bcrypt. This ensures that passphrases longer than the 72-char bcrypt limit won't be effectively truncated --- instead, their full entropy will be available (up to a limit of 512 bits, which at 64 bytes is fully bcrypt-able). We could consider SHA3-512 instead.

Another thing: going forward, I think we should enforce that passwords cannot contain spaces (so if we implement password change, or other operations requiring password confirmation, through nickserv, the messages will be easy to parse).