First draft.
+ Following best practices when hashing and storing passwords and other + authenticator secrets impacts a great deal more than just a users identity. + It also effects usability, and backwards compatibility by determining what + authentication and authorization mechanisms can be used. + Unfortunately, aside from mandating the use of SCRAM-SHA-1 in &rfc6120;, and + recommending at least 4096 rounds of PBKDF2 in &rfc5802; (a + number which is now woefully inadequate), no general recommendations for + best practices in password storage, transmission, or key derivation function + tuning exist in the XMPP ecosystem. +
++ Many of the recommendations in this document were taken from + &nistsp800-63b; and &nistsp800-132;. +
++ This document makes specific recommendations for best practices on the + public Jabber network for both clients and servers. + It does not attempt to address private networks or proprietary services + which may have different requirements, use cases, and security models. + These recommendations include the hashing and storage of memorized secrets + and other authenticators, authentication, and compatibility between clients + and servers with respect to authentication. +
++ To keep the length of this document manageable, we assume basic familiarity + with password storage and handling, common terms, and cryptographic + operations. + For an overview of basic password security see the &owasppasswords; + maintained by &OWASP;. +
++ Many terms used in this document are defined in &nistsp800-63-3; Appendix + A.1 and in &nistsp800-132; §3.1. + Throughout this document the term "password" is used to mean any password, + passphrase, PIN, or other memorized secret. +
++ Clients and servers must already implement the SASL mechanisms listed in RFC + 6120 §13.8.1 For Authentication Only. + These mechanisms are: +
++ In addition, clients and servers SHOULD support the following SCRAM variants + defined in &rfc7677;: +
++ Clients SHOULD NOT invent their own mechanisms that have not been + standardized by the IETF, the XSF, or another reputable standards body. +
++ Clients MUST NOT implement any mechanism with a usage status of "OBSOLETE", + "MUST NOT be used", or "LIMITED" in the &ianasasl;. + Similarly, any mechanism that depends on a hash function listed as "MUST + NOT" in &xep0414; MUST NOT be used. + This means that the following mechanisms which were commonly used with XMPP + in the past MUST NOT be supported: +
++ Clients maintain a list of preferred SASL mechanisms, generally ordered by + perceived strength to enable strong authentication (RFC 6120 §6.3.3 + Mechanism Preferences). + To prevent downgrade attacks by a malicious actor that has successfully + man in the middled a connection, or compromised a trusted server's + configuration, clients SHOULD implement "mechanism pinning". + That is, after the first successful authentication with a strong + mechanism, clients SHOULD make a record of the authentication and + thereafter only advertise and use mechanisms of equal or higher perceived + strength. +
++ For reference, the following mechanisms are ordered by their perceived + strength from strongest to weakest with mechanisms of equal strength on + the same line. + This list is a non-normative example and does not indicate that these + mechanisms should or should not be supported: +
++ Clients SHOULD always store authenticators in a trusted and encrypted + keystore such as the system keystore, or an encrypted store created + specifically for the clients use. + They SHOULD NOT store authenticators as plain text. +
++ If clients know that they will only ever authenticate using a mechanism + such as SCRAM where the original password is not needed (for example if + the mechanism has been pinned) they SHOULD store the SCRAM bits or the + hashed and salted password instead of the original password. + However, if backwards compatibility with servers that only support the + PLAIN mechanism or other mechanisms that require using the original + password is required, clients MAY choose to store the original password + so long as an appropriate keystore is used. +
++ Servers MUST NOT support any mechanism that would require authenticators + to be stored in such a way that they could be recovered in plain text from + the stored information. + This includes mechanisms that store authenticators using reversable + encryption, obsolete hashing mechanisms such as MD5, and hashes that are + unsuitable for use with authenticators such as SHA256. +
++ Servers MUST always store passwords only after they have been salted and + hashed. + If multiple hashes are supported for use with SCRAM, for example + SCRAM-SHA-1 and SCRAM-SHA-256, separate salted and hashed passwords SHOULD + be calculated and stored for each mechanism so that users can log in with + multiple clients that support only some of the mechanisms. +
++ A distinct salt SHOULD be used for each user, and each SCRAM family + supported. + Salts MUST be generated using a cryptographically secure random number + generator. + The salt MAY be stored in the same datastore as the password. + If it is stored alongside the password, it SHOULD be combined with a + pepper stored in the application configuration, an environment variable, + or some other location other than the datastore containing the salts. +
++ When authenticating using PLAIN or similar mechanisms that involve + transmitting the original password to the server the password MUST + be hashed and compared against the salted and hashed password in the + database using a constant time comparison. +
++ Each time a password is changed or reset, a new random salt should be + created and the iteration count and pepper (if applicable) should be + updated to the latest value required by server policy. +
++ If a pepper is used, consideration should be taken to ensure that it can + be easily rotated. + For example, multiple peppers could be stored with new passwords and + reset passwords using the latest pepper. + A hash of the pepper using a cryptographically secure hash function such + as SHA256 could then be stored in the database next to the salt so that + future logins can identify which pepper in the list was used. + This is just one example, pepper rotation schemes are outside the scope of + this document. +
++ Because the PBKDF2 key derivation function (&rfc8018;) is used by + SCRAM-SHA-1 which is mandated for use in XMPP, this document recommends it + for password storage. + Servers SHOULD use the following parameters when applying PBKDF2: +
++ The minimum iteration count may be tuned to the specific system on which + password hashing is taking place. +
++ Clients and servers SHOULD enforce a minimum length of 8 characters for user + passwords. + If using a mechanism such as PLAIN where the server performs hashing on the + original password, a maximum length between 64 and 128 characters MAY be + imposed to prevent denial of service (DoS) attacks. + Passwords SHOULD be required to conform to the Opaque String profile of + &rfc8265;. + No other password restrictions should be applied. +
++ The SCRAM suite of SASL mechanisms are recommended in this document, + however, there is currently no way to force a password reset. + This reduces upgrade agility if a weakness is discovered in SCRAM and means + that new, untested, SCRAM-based or SCRAM-like mechanisms should be added + with caution. +
++ This document mentions many hash functions that are already in + use in the XMPP ecosystem, or that have been used in the past. + It does not make recommendations for what functions should or should not be + used in new applications. + For recommendations about the use of hash functions and their security + implications, see &xep0414; +
++ This document contains recommendations that are likely to change over time. + It should be reviewed yearly to ensure that it remains accurate and up to + date. + Many of the recommendations in this document were taken from the + &owasppasswords;, which can be used as a reference when making updates. +
++ This document requires no interaction with &IANA;. +
++ No namespaces or parameters need to be registered with the ®ISTRAR; as a + result of this document. +
+