draft-whited-kitten-password-storage-02.txt   draft-whited-kitten-password-storage-03.txt 
Common Authentication Technology Next Generation S. Whited Common Authentication Technology Next Generation S. Whited
Internet-Draft 28 April 2020 Internet-Draft 6 May 2020
Intended status: Experimental Intended status: Experimental
Expires: 30 October 2020 Expires: 7 November 2020
Best practices for password hashing and storage Best practices for password hashing and storage
draft-whited-kitten-password-storage-02 draft-whited-kitten-password-storage-03
Abstract Abstract
This document outlines best practices for handling user passwords and This document outlines best practices for handling user passwords and
other authenticator secrets in client-server systems making use of other authenticator secrets in client-server systems making use of
SASL. SASL.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 30 October 2020. This Internet-Draft will expire on 7 November 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 26 skipping to change at page 2, line 26
4.3. Authentication and Rotation . . . . . . . . . . . . . . . 6 4.3. Authentication and Rotation . . . . . . . . . . . . . . . 6
5. KDF Recommendations . . . . . . . . . . . . . . . . . . . . . 6 5. KDF Recommendations . . . . . . . . . . . . . . . . . . . . . 6
5.1. Argon2 . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Argon2 . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Bcrypt . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Bcrypt . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.4. Scrypt . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.4. Scrypt . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Password Complexity Requirements . . . . . . . . . . . . . . 8 6. Password Complexity Requirements . . . . . . . . . . . . . . 8
7. Internationalization Considerations . . . . . . . . . . . . . 9 7. Internationalization Considerations . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Following best practices when hashing and storing passwords for use Following best practices when hashing and storing passwords for use
with SASL impacts a great deal more than just a users identity. It with SASL impacts a great deal more than just a user's identity. It
also effects usability, backwards compatibility, and interoperability also affects usability, backwards compatibility, and interoperability
by determining what authentication and authorization mechanisms can by determining what authentication and authorization mechanisms can
be used. be used.
1.1. Conventions and Terminology 1.1. Conventions and Terminology
Various security-related terms are to be understood in the sense Various security-related terms are to be understood in the sense
defined in [RFC4949]. Some may also be defined in [NISTSP63-3] defined in [RFC4949]. Some may also be defined in [NISTSP63-3]
Appendix A.1 and in [NISTSP132] section 3.1. Appendix A.1 and in [NISTSP132] section 3.1.
Throughout this document the term "password" is used to mean any Throughout this document the term "password" is used to mean any
skipping to change at page 4, line 30 skipping to change at page 4, line 30
4. PLAIN 4. PLAIN
5. DIGEST-MD5, CRAM-MD5 5. DIGEST-MD5, CRAM-MD5
The EXTERNAL mechanism defined in [RFC4422] appendix A is placed at The EXTERNAL mechanism defined in [RFC4422] appendix A is placed at
the top of the list. However, its perceived strength depends on the the top of the list. However, its perceived strength depends on the
underlying authentication protocol. In this example, we assume that underlying authentication protocol. In this example, we assume that
TLS [RFC8446] services are being used which can provide a strong TLS [RFC8446] services are being used which can provide a strong
authenticator assurance level. authenticator assurance level.
The channel binding ("-PLUS") variants of SCRAM are listed above The channel binding ("-PLUS") variants of SCRAM [RFC5802] are listed
their non-channel binding cousins, but may not always be available above their non-channel binding cousins, but may not always be
depending on the type of channel binding data available to the SASL available depending on the type of channel binding data available to
negotiator. the SASL negotiator.
The PLAIN mechanism sends the username and password in plain text, The PLAIN mechanism sends the username and password in plain text,
but does allow for the use of a strong key derivation function for but does allow for the use of a strong key derivation function for
the stored version of the password on the server. the stored version of the password on the server.
Finally, the DIGEST-MD5 and CRAM-MD5 mechanisms are listed last Finally, the DIGEST-MD5 and CRAM-MD5 mechanisms are listed last
because they use weak hashes and ciphers and prevent the server from because they use weak hashes and ciphers and prevent the server from
storing passwords using a strong key derivation function. For a list storing passwords using a strong key derivation function. For a list
of problems with DIGEST-MD5 see [RFC6331]. of problems with DIGEST-MD5 see [RFC6331].
3.2. Storage 3.2. Storage
Clients SHOULD always store authenticators in a trusted and encrypted Clients SHOULD always store authenticators in a trusted and encrypted
keystore such as the system keystore, or an encrypted store created keystore such as the system keystore, or an encrypted store created
specifically for the clients use. They SHOULD NOT store specifically for the clients use. They SHOULD NOT store
authenticators as plain text. authenticators as plain text.
If clients know that they will only ever authenticate using a If clients know that they will only ever authenticate using a
mechanism such as SCRAM where the original password is not needed mechanism such as SCRAM [RFC5802] where the original password is not
after the first authentication attempt they SHOULD store the SCRAM needed after the first authentication attempt they SHOULD store the
bits or the hashed and salted password instead of the original SCRAM bits or the hashed and salted password instead of the original
password. However, if backwards compatibility with servers that only password. However, if backwards compatibility with servers that only
support the PLAIN mechanism or other mechanisms that require using support the PLAIN mechanism or other mechanisms that require using
the original password is required, clients MAY choose to store the the original password is required, clients MAY choose to store the
original password so long as an appropriate keystore is used. original password so long as an appropriate keystore is used.
4. Server Best Practices 4. Server Best Practices
4.1. Additional SASL Requirements 4.1. Additional SASL Requirements
Servers MUST NOT support any mechanism that would require Servers MUST NOT support any mechanism that would require
skipping to change at page 5, line 33 skipping to change at page 5, line 33
unsuitable for use with authenticators such as SHA256. unsuitable for use with authenticators such as SHA256.
4.2. Storage 4.2. Storage
Servers MUST always store passwords only after they have been salted Servers MUST always store passwords only after they have been salted
and hashed. A distinct salt SHOULD be used for each user, and each and hashed. A distinct salt SHOULD be used for each user, and each
SCRAM family supported. Salts MUST be generated using a SCRAM family supported. Salts MUST be generated using a
cryptographically secure random number generator. The salt MAY be cryptographically secure random number generator. The salt MAY be
stored in the same datastore as the password. If it is stored stored in the same datastore as the password. If it is stored
alongside the password, it SHOULD be combined with a pepper stored in alongside the password, it SHOULD be combined with a pepper stored in
the application configuration, an environment variable, or some other the application configuration, an environment variable, or some
location other than the datastore containing the salts. location other than the datastore containing the salts.
The following restrictions MUST be observed when generating salts and The following restrictions MUST be observed when generating salts and
peppers: peppers:
+-----------------------+----------+ +-----------------------+----------+
| Parameter | Value | | Parameter | Value |
+=======================+==========+ +=======================+==========+
| Minimum Salt Length | 16 bytes | | Minimum Salt Length | 16 bytes |
+-----------------------+----------+ +-----------------------+----------+
skipping to change at page 7, line 36 skipping to change at page 7, line 36
+=========================+=======+ +=========================+=======+
| Recommended Cost | 12 | | Recommended Cost | 12 |
+-------------------------+-------+ +-------------------------+-------+
| Maximum Password Length | 64 | | Maximum Password Length | 64 |
+-------------------------+-------+ +-------------------------+-------+
Table 3: Bcrypt Parameters Table 3: Bcrypt Parameters
5.3. PBKDF2 5.3. PBKDF2
PBKDF2 [RFC8018] is used by the SCRAM family of SASL mechanisms. PBKDF2 [RFC8018] is used by the SCRAM [RFC5802] family of SASL
mechanisms.
+-----------------------------+-------------------------------------+ +-----------------------------+-------------------------------------+
| Parameter | Value | | Parameter | Value |
+=============================+=====================================+ +=============================+=====================================+
| Minimum iteration count (c) | 10,000 | | Minimum iteration count (c) | 10,000 |
+-----------------------------+-------------------------------------+ +-----------------------------+-------------------------------------+
| Hash | SHA256 | | Hash | SHA256 |
+-----------------------------+-------------------------------------+ +-----------------------------+-------------------------------------+
| Output length (dkLen) | 64 (or length of | | Output length (dkLen) | 64 (or length of |
| | chosen hash, hLen) | | | chosen hash, hLen) |
skipping to change at page 9, line 31 skipping to change at page 9, line 31
authenticated. authenticated.
8. Security Considerations 8. Security Considerations
This document contains recommendations that are likely to change over This document contains recommendations that are likely to change over
time. It should be reviewed regularly to ensure that it remains time. It should be reviewed regularly to ensure that it remains
accurate and up to date. Many of the recommendations in this accurate and up to date. Many of the recommendations in this
document were taken from [OWASP.CS.passwords], [NISTSP63b], and document were taken from [OWASP.CS.passwords], [NISTSP63b], and
[NISTSP132]. [NISTSP132].
The "-PLUS" variants of SCRAM support channel binding to their The "-PLUS" variants of SCRAM [RFC5802] support channel binding to
underlying security layer, but lack a mechanism for negotiating what their underlying security layer, but lack a mechanism for negotiating
type of channel binding to use. In [RFC5802] the tls-unique what type of channel binding to use. In [RFC5802] the tls-unique
[RFC5929] channel binding mechanism is specified as the default, and [RFC5929] channel binding mechanism is specified as the default, and
it is therefore likely to be used in most applications that support it is therefore likely to be used in most applications that support
channel binding. However, in the absence of the TLS extended master channel binding. However, in the absence of the TLS extended master
secret fix [RFC7627] the tls-unique and tls-server-endpoint channel secret fix [RFC7627] and the renegotiation indication TLS extension
binding data does not provide enough information to uniquely identify [RFC5746] the tls-unique and tls-server-endpoint channel binding data
a session. Before advertising a channel binding SCRAM mechanism, can be forged by an attacker that can MITM the connection. Before
entities MUST ensure that the TLS extended master secret fix is in advertising a channel binding SASL mechanism, entities MUST ensure
place or that the connection has not been renegotiated. that both the TLS extended master secret fix and the renegotiation
indication extension are in place and that the connection has not
been renegotiated.
For TLS 1.3 [RFC8446] no channel binding types are currently defined. For TLS 1.3 [RFC8446] no channel binding types are currently defined.
Channel binding SASL mechanisms MUST NOT be advertised or negotiated Channel binding SASL mechanisms MUST NOT be advertised or negotiated
over a TLS 1.3 channel until such types are defined. over a TLS 1.3 channel until such types are defined.
9. IANA Considerations 9. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
10. References 10. References
skipping to change at page 10, line 21 skipping to change at page 10, line 24
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
"Transport Layer Security (TLS) Renegotiation Indication
Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,
<https://www.rfc-editor.org/info/rfc5746>.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
<https://www.rfc-editor.org/info/rfc5929>. <https://www.rfc-editor.org/info/rfc5929>.
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
Langley, A., and M. Ray, "Transport Layer Security (TLS) Langley, A., and M. Ray, "Transport Layer Security (TLS)
Session Hash and Extended Master Secret Extension", Session Hash and Extended Master Secret Extension",
RFC 7627, DOI 10.17487/RFC7627, September 2015, RFC 7627, DOI 10.17487/RFC7627, September 2015,
<https://www.rfc-editor.org/info/rfc7627>. <https://www.rfc-editor.org/info/rfc7627>.
skipping to change at page 13, line 10 skipping to change at page 13, line 10
[SCRYPT] Percival, C., "Stronger key derivation via sequential [SCRYPT] Percival, C., "Stronger key derivation via sequential
memory-hard functions", memory-hard functions",
BSDCan'09 http://www.tarsnap.com/scrypt/scrypt.pdf, May BSDCan'09 http://www.tarsnap.com/scrypt/scrypt.pdf, May
2009. 2009.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The author would like to thank the civil servants at the National The author would like to thank the civil servants at the National
Institute of Standards and Technology for their work on the Special Institute of Standards and Technology for their work on the Special
Publications series. U.S. executive agencies are an undervalued Publications series. U.S. executive agencies are an undervalued
national treasure, and we should all work to protect them and the p national treasure, and they deserve our thanks.
Thanks also to Cameron Paul for his review and suggestions. Thanks also to Cameron Paul and Thomas Copeland for their reviews and
suggestions.
Author's Address Author's Address
Sam Whited Sam Whited
Atlanta, GA Atlanta, GA
United States of America United States of America
Email: sam@samwhited.com Email: sam@samwhited.com
URI: https://blog.samwhited.com/ URI: https://blog.samwhited.com/
 End of changes. 15 change blocks. 
26 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/