draft-ietf-kitten-password-storage-01.txt   draft-ietf-kitten-password-storage-02.txt 
Common Authentication Technology Next Generation S. Whited Common Authentication Technology Next Generation S. Whited
Internet-Draft 29 October 2020 Internet-Draft 22 November 2020
Intended status: Best Current Practice Intended status: Best Current Practice
Expires: 2 May 2021 Expires: 26 May 2021
Best practices for password hashing and storage Best practices for password hashing and storage
draft-ietf-kitten-password-storage-01 draft-ietf-kitten-password-storage-02
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 2 May 2021. This Internet-Draft will expire on 26 May 2021.
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 18 skipping to change at page 2, line 18
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2
2. SASL Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 3 2. SASL Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 3
3. Client Best Practices . . . . . . . . . . . . . . . . . . . . 3 3. Client Best Practices . . . . . . . . . . . . . . . . . . . . 3
3.1. Mechanism Pinning . . . . . . . . . . . . . . . . . . . . 4 3.1. Mechanism Pinning . . . . . . . . . . . . . . . . . . . . 4
3.2. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Server Best Practices . . . . . . . . . . . . . . . . . . . . 5 4. Server Best Practices . . . . . . . . . . . . . . . . . . . . 5
4.1. Additional SASL Requirements . . . . . . . . . . . . . . 5 4.1. Additional SASL Requirements . . . . . . . . . . . . . . 5
4.2. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 10
skipping to change at page 4, line 24 skipping to change at page 4, line 24
perceived strength. perceived strength.
The following mechanisms are ordered by their perceived strength from The following mechanisms are ordered by their perceived strength from
strongest to weakest with mechanisms of equal strength on the same strongest to weakest with mechanisms of equal strength on the same
line. The remainder of this section is merely informative. In line. The remainder of this section is merely informative. In
particular this example does not imply that mechanisms in this list particular this example does not imply that mechanisms in this list
should or should not be implemented. should or should not be implemented.
1. EXTERNAL 1. EXTERNAL
2. SCRAM-SHA-1-PLUS, SCRAM-SHA-256-PLUS 2. SCRAM-SHA-256-PLUS
3. SCRAM-SHA-1, SCRAM-SHA-256 3. SCRAM-SHA-1-PLUS
4. PLAIN 4. SCRAM-SHA-256
5. DIGEST-MD5, CRAM-MD5 5. SCRAM-SHA-1
6. PLAIN
7. 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. TLS [RFC8446] services are being used.
The channel binding ("-PLUS") variants of SCRAM [RFC5802] are listed The channel binding ("-PLUS") variants of SCRAM [RFC5802] are listed
above their non-channel binding cousins, but may not always be above their non-channel binding cousins, but may not always be
available depending on the type of channel binding data available to available depending on the type of channel binding data available to
the SASL negotiator. the SASL negotiator.
skipping to change at page 5, line 34 skipping to change at page 5, line 39
Servers MUST NOT support any mechanism that would require Servers MUST NOT support any mechanism that would require
authenticators to be stored in such a way that they could be authenticators to be stored in such a way that they could be
recovered in plain text from the stored information. This includes recovered in plain text from the stored information. This includes
mechanisms that store authenticators using reversable encryption, mechanisms that store authenticators using reversable encryption,
obsolete hashing mechanisms such as MD5 or hashing mechanisms that obsolete hashing mechanisms such as MD5 or hashing mechanisms that
are cryptographically secure but designed for speed such as SHA256. are cryptographically secure but designed for speed 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 using a strong KDF. A distinct salt SHOULD be used for peppered (if possible with the given authentication mechanism), and
each user, and each SCRAM family supported. Salts SHOULD be hashed using a strong KDF. A distinct salt SHOULD be used for each
generated using a cryptographically secure random number generator. user, and each SCRAM family supported. Salts SHOULD be generated
The salt MAY be stored in the same datastore as the password. If it using a cryptographically secure random number generator. The salt
is stored alongside the password, it SHOULD be combined with a pepper MAY be stored in the same datastore as the password. A pepper stored
stored in the application configuration, or a secure location other in the application configuration, or a secure location other than the
than the datastore containing the salts. datastore containing the salts, SHOULD be combined with the password
before hashing if possible with the given authentication mechanism.
Peppers SHOULD NOT be combined with the salt because the salt is not
secret and may appear in the final hash output.
The following restrictions MUST be observed when generating salts and The following restrictions MUST be observed when generating salts and
peppers, more up to date numbers may be found in peppers, more up to date numbers may be found in
[OWASP.CS.passwords]. [OWASP.CS.passwords].
+=======================+==========+ +=======================+==========+
| Parameter | Value | | Parameter | Value |
+=======================+==========+ +=======================+==========+
| Minimum Salt Length | 16 bytes | | Minimum Salt Length | 16 bytes |
+-----------------------+----------+ +-----------------------+----------+
skipping to change at page 7, line 9 skipping to change at page 7, line 14
5.1. Argon2 5.1. Argon2
Argon2 [ARGON2ESP] is the 2015 winner of the Password Hashing Argon2 [ARGON2ESP] is the 2015 winner of the Password Hashing
Competition and has been recomended by OWASP for password hashing. Competition and has been recomended by OWASP for password hashing.
Security considerations, test vectors, and parameters for tuning Security considerations, test vectors, and parameters for tuning
argon2 can be found in [I-D.irtf-cfrg-argon2]. They are copied here argon2 can be found in [I-D.irtf-cfrg-argon2]. They are copied here
for easier reference. for easier reference.
+===========================+==============+ +==================================+==============+
| Parameter | Value | | Parameter | Value |
+===========================+==============+ +==================================+==============+
| Degree of parallelism (p) | 1 | | Degree of parallelism (p) | 1 |
+---------------------------+--------------+ +----------------------------------+--------------+
| Memory size (m) | 32*1024 | | Minimum memory size (m) | 32*1024 |
+---------------------------+--------------+ +----------------------------------+--------------+
| Number of iterations (t) | 1 | | Minimum number of iterations (t) | 1 |
+---------------------------+--------------+ +----------------------------------+--------------+
| Algorithm type (y) | Argon2id (2) | | Algorithm type (y) | Argon2id (2) |
+---------------------------+--------------+ +----------------------------------+--------------+
Table 2: Argon Parameters Table 2: Argon Parameters
5.2. Bcrypt 5.2. Bcrypt
bcrypt [BCRYPT] is a Blowfish-based KDF that is the current OWASP bcrypt [BCRYPT] is a Blowfish-based KDF that is the current OWASP
recommendation for password hashing. recommendation for password hashing.
+=========================+=======================+ +=========================+=======================+
| Parameter | Value | | Parameter | Value |
+=========================+=======================+ +=========================+=======================+
| Recommended Cost | 12 | | Recommended Cost | 12 |
skipping to change at page 8, line 25 skipping to change at page 8, line 25
Table 4: PBKDF2 Parameters Table 4: PBKDF2 Parameters
5.4. Scrypt 5.4. Scrypt
The [SCRYPT] KDF is designed to be memory-hard and sequential memory- The [SCRYPT] KDF is designed to be memory-hard and sequential memory-
hard to prevent against custom hardware based attacks. hard to prevent against custom hardware based attacks.
Security considerations, test vectors, and further notes on tuning Security considerations, test vectors, and further notes on tuning
scrypt may be found in [RFC7914]. scrypt may be found in [RFC7914].
+===========+================+ +=======================================+==================+
| Parameter | Value | | Parameter | Value |
+===========+================+ +=======================================+==================+
| N | 32768 (N=2^15) | | Minimum CPU/Memory cost parameter (N) | 32768 (N=2^15) |
+-----------+----------------+ +---------------------------------------+------------------+
| r | 8 | | Blocksize (r) | 8 |
+-----------+----------------+ +---------------------------------------+------------------+
| p | 1 | | Parallelization parameter (p) | 1 |
+-----------+----------------+ +---------------------------------------+------------------+
| Output length (dkLen) | hLen (length of |
| | the chosen hash) |
+---------------------------------------+------------------+
Table 5: Scrypt Parameters Table 5: Scrypt Parameters
6. Password Complexity Requirements 6. Password Complexity Requirements
Before any other password complexity requirements are checked, the Before any other password complexity requirements are checked, the
preparation and enforcement steps of the OpaqueString profile of preparation and enforcement steps of the OpaqueString profile of
[RFC8265] SHOULD be applied (for more information see the [RFC8265] SHOULD be applied (for more information see the
Internationalization Considerations section). Entities SHOULD Internationalization Considerations section). Entities SHOULD
enforce a minimum length of 8 characters for user passwords. If enforce a minimum length of 8 characters for user passwords. If
 End of changes. 13 change blocks. 
38 lines changed or deleted 48 lines changed or added

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