From 26e65e10129202a4a697e73c0111b6baa6dfae56 Mon Sep 17 00:00:00 2001 From: Sam Whited Date: Sun, 19 Apr 2020 15:34:24 -0400 Subject: [PATCH] =?UTF-8?q?Proto=20XEP:=20"Best=20practices=20for=20passwo?= =?UTF-8?q?rd=20hashing=E2=80=A6"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- inbox/password-storage.xml | 306 +++++++++++++++++++++++++++++++++++++ 1 file changed, 306 insertions(+) create mode 100644 inbox/password-storage.xml diff --git a/inbox/password-storage.xml b/inbox/password-storage.xml new file mode 100644 index 00000000..b79c1508 --- /dev/null +++ b/inbox/password-storage.xml @@ -0,0 +1,306 @@ + +Open Web Application Security Project (OWASP) The Open Web Application Security Project (OWASP, or OWASP Foundation) is a nonprofit foundation that works to improve the security of software. For further information, see <https://owasp.org/>." > + OWASP Password Storage Cheat Sheet OWASP Cheat Sheet Series for password storage <https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html>." > + RFC 2195 RFC 2195: IMAP/POP AUTHorize Extension for Simple Challenge/Response <http://tools.ietf.org/html/rfc2195>." > + RFC 7677 RFC 7677: SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms <http://tools.ietf.org/html/rfc7677>." > + RFC 8018 RFC 8018: PKCS #5: Password-Based Cryptography Specification Version 2.1 <http://tools.ietf.org/html/rfc8018>." > + RFC 8265 RFC 8265: PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application ProtocolePRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocolsration, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords <http://tools.ietf.org/html/rfc8265>." > + Digital Identity Guidelines Digital Identity Guidelines, NIST Special Publication 800-63-3 <https://doi.org/10.6028/NIST.SP.800-63-3>." > + Digital Identity Guidelines: Authentication and Lifecycle Management Digital Identity Guidelines: Authentication and Lifecycle Management, NIST Special Publication 800-63B <https://doi.org/10.6028/NIST.SP.800-63b>." > + Recommendation for Password-Based Key Derivation, Part 1: Storage Applications Recommendation for Password-Based Key Derivation, Part 1: Storage Applications, NIST Special Publication 800-132 <https://doi.org/10.6028/NIST.SP.800-132>." > + +%ents; +]> + + +
+ Best practices for password hashing and storage + + This document outlines best practices for handling user passwords on the + public Jabber network for both clients and servers. + + &LEGALNOTICE; + xxxx + ProtoXEP + Informational + Standards + Council + + + + passwords + &sam; + + 0.0.1 + 2020-04-19 + ssw +

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. +

+
+ +
Pepper
+
+ A secret added to a password hash like a salt. + Unlike a salt, peppers are secret and not unique. + They must not be stored alongside the hashed password. +
+ +
+ + +

+ Clients and servers must already implement the SASL mechanisms listed in RFC + 6120 §13.8.1 For Authentication Only. + These mechanisms are: +

+
    +
  • SCRAM-SHA-1
    • +
  • SCRAM-SHA-1-PLUS
    • +
+

+ In addition, clients and servers SHOULD support the following SCRAM variants + defined in &rfc7677;: +

+
    +
  • SCRAM-SHA-256
    • +
  • SCRAM-SHA-256-PLUS
    • +
+

+ 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: +

+
    +
  • CRAM-MD5 (&rfc2195;)
    • +
  • DIGEST-MD5 (&rfc6331;)
    • +
+ + + +

+ 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: +

+
    +
  1. EXTERNAL
    2. +
  2. SCRAM-SHA-1-PLUS, SCRAM-SHA-256-PLUS
    3. +
  3. SCRAM-SHA-1, SCRAM-SHA-256
    4. +
  4. PLAIN
    5. +
  5. DIGEST-MD5, CRAM-MD5
    6. +
+ + +

+ 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: +

+
+ +
Minimum iterations
+
10,000 (100,000 for higher security environments)
+ + +
Minimum salt length
+
16 bytes
+ + +
Minimum pepper length
+
32 bytes
+ +
+

+ 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. +

+ +