Consider removing SCRAM-SHA-512 support
SamWhited opened this issue · 2 comments
The SCRAM-SHA1 and SCRAM-SHA-256 SASL mechanisms are standardized by the IETF. However, there is no standardized mechanism for SCRAM-SHA-512. Since it is not supported by any XMPP clients, and does not provide any known security benefit over either of the other SCRAM mechanisms (since the hash is just used in an HMAC), please consider removing the SHA-512 mechanism. If the mechanism is left in, and eventually a SCRAM-SHA-512 mechanism is created by the IETF but it differs somehow from the other mechanisms, you will have an incompatible version. This also may encourage other developers to implement the non-standard mechanism and/or to not support the actual standardized mechanisms out of some misguided idea that bigger numbers means that it is somehow "more secure". We don't want to have to clean up a mess later, or encourage other XMPP stacks to invent their own mechanisms which may only work with one or two clients and servers when safe, standardized, mechanisms have already been thought through by a group with expertise in these matters.
Thanks for your consideration.
Another good reason to remove this that I just thought of is that if you want to store hashed passwords in the database (see #62) you'd need to store a separate salted password for every single hash you support with SCRAM. Otherwise if eg. Conversations logs in with SCRAM-SHA-256 and then the user tries to log in from their desktop with a client that only supports SCRAM-SHA-1, they won't be able to use that client anymore because we only stored the SCRAM-SHA-256 salted password (or visa-versa). Supporting the non-standard ones means we need to store three hashes instead of just two and makes this much harder even though mainstream clients don't support it because it's not standardized.
@ortuman: Several XMPP clients support SCRAM-SHA-512(-PLUS)...