Update to match draft-ietf-kitten-password-storage-01.
Fix reference to external document
Fix reference to external document.
- Many terms used in this document are defined in &nistsp800-63-3; Appendix - A.1 and in &nistsp800-132; §3.1. + Various security-related terms are to be understood in the sense + defined in &rfc4949; + Some may also be defined in 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.
++ Other common terms used throughout this document include: +
+ The EXTERNAL mechanism defined in &rfc4422; appendix A is placed at + the top of the list. + However, its perceived strength depends on the underlying authentication + protocol. + In this example, we assume that TLS (&rfc8446;) services are being used. +
++ The channel binding ("-PLUS") variants of SCRAM (&rfc5802;) are listed + above their non-channel binding cousins, but may not always be + available depending on the type of channel binding data available to + the SASL negotiator. +
++ The PLAIN mechanism sends the username and password in plain text, + but does allow for the use of a strong key derivation function (KDF) + for the stored version of the password on the server. +
++ Finally, the DIGEST-MD5 and CRAM-MD5 mechanisms are listed last + because they use weak hashes and ciphers and prevent the server from + storing passwords using a KDF. For a list of problems with DIGEST- + MD5 see &rfc6331;. +
@@ -200,7 +255,7 @@
Servers MUST always store passwords only after they have been salted and
- hashed.
+ hashed using a strong KDF.
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
@@ -216,6 +271,25 @@
pepper stored in the application configuration, an environment variable,
or some other location other than the datastore containing the salts.
+ The following minimum restrictions MUST be observed when generating salts
+ and peppers.
+ More up to date numbers may be found in &owasppasswords;
+
@@ -251,16 +325,16 @@
@@ -270,17 +344,34 @@
+
- Clients and servers SHOULD enforce a minimum length of 8 characters for user - passwords. + Before any other password complexity requirements are checked, the + preparation and enforcement steps of the OpaqueString profile of &rfc8265; + SHOULD be applied (for more information see the Internationalization + Considerations section). + Entities 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. + Entities SHOULD NOT apply any other password restrictions. +
++ In addition to these password complexity requirements, servers SHOULD + maintain a password blocklist and reject attempts by a claimant to use + passwords on the blocklist during registration or password reset. + The contents of this blocklist are a matter of server policy. + Some common recommendations include lists of common passwords that are not + otherwise prevented by length requirements, and passwords present in known + breaches.
+ This document contains recommendations that are likely to change over time. + It should be reviewed regularly to ensure that it remains accurate and up to + date. + Many of the recommendations in this document were taken from + &owasppasswords;, &nistsp800-63b;, and &nistsp800-132;. +
The SCRAM suite of SASL mechanisms are recommended in this document, however, there is currently no way to force a password reset. @@ -288,6 +379,22 @@ that new, untested, SCRAM-based or SCRAM-like mechanisms should be added with caution.
++ The "-PLUS" variants of SCRAM support channel binding to their underlying + security layer, but lack a mechanism for negotiating what type of channel + binding to use. + In &rfc5802; the tls-unique (&rfc5929;) channel + binding mechanism is specified as the default, and it is therefore likely to + be used in most applications that support channel binding. + However, in the absence of the TLS extended master secret fix (&rfc7627;) + and the renegotiation indication TLS extension (&rfc5746;) the tls-unique + and tls-server-endpoint channel binding data can be forged by an attacker + that can MITM the connection. + Before advertising a channel binding SASL mechanism, entities MUST ensure + that both the TLS extended master secret fix and the renegotiation + indication extension are in place and that the connection has not been + renegotiated. +
This document mentions many hash functions that are already in use in the XMPP ecosystem, or that have been used in the past. @@ -297,11 +404,28 @@ 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. + For TLS 1.3 no channel binding types are currently defined. Channel binding + SASL mechanisms MUST NOT be advertised or negotiated over a TLS 1.3 channel + until such types are defined. +
++ The PRECIS framework (Preparation, Enforcement, and Comparison of + Internationalized Strings) defined in &rfc8264; is used to enforce + internationalization rules on strings and to prevent common application + security issues arrising from allowing the full range of Unicode codepoints + in usernames, passwords, and other identifiers. + The OpaqueString profile of &rfc8265; is used in this document to ensure + that codepoints in passwords are treated carefully and consistently. + This ensures that users typing certain characters on different keyboards + that may provide different versions of the same character will still be able + to log in. + For example, some keyboards may output the full-width version of a character + while other keyboards output the half-width version of the same character. + The Width Mapping rule of the OpaqueString profile addresses this and + ensures that comparison succeeds and the claimant is able to be + authenticated.