draft-whited-kitten-password-storage-01.txt   draft-whited-kitten-password-storage-02.txt 
Common Authentication Technology Next Generation S. Whited Common Authentication Technology Next Generation S. Whited
Internet-Draft 28 April 2020 Internet-Draft 28 April 2020
Intended status: Experimental Intended status: Experimental
Expires: 30 October 2020 Expires: 30 October 2020
Best practices for password hashing and storage Best practices for password hashing and storage
draft-whited-kitten-password-storage-01 draft-whited-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 2, line 16 skipping to change at page 2, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . . . . . . . 3 3.1. Mechanism Pinning . . . . . . . . . . . . . . . . . . . . 3
3.2. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Bcrypt . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.4. Scrypt . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.4. Scrypt . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Password Complexity Requirements . . . . . . . . . . . . . . 7 6. Password Complexity Requirements . . . . . . . . . . . . . . 8
7. Internationalization Considerations . . . . . . . . . . . . . 8 7. Internationalization Considerations . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 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 users identity. It
also effects usability, backwards compatibility, and interoperability also effects 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.
Many of the recommendations in this document were taken from
[NIST.SP.800-63b] and [NIST.SP.800-132].
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 [NIST.SP.800-63-3] defined in [RFC4949]. Some may also be defined in [NISTSP63-3]
Appendix A.1 and in [NIST.SP.800-132] 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
password, passphrase, PIN, or other memorized secret. password, passphrase, PIN, or other memorized secret.
The term "pepper" is used to mean a secret added to a password hash Other common terms used throughout this document include:
like a salt. Unlike a salt, peppers are secret, not unique, and are
not stored alongside the hashed password.
Mechanism pinning is a security mechanism which allows SASL clients Pepper A secret added to a password hash like a salt. Unlike a
to resist downgrade attacks. Clients that implement mechanism salt, peppers are secret and not unique. They must not be stored
pinning remember the perceived strength of the SASL mechanism used in alongside the hashed password.
a previous successful authentication attempt and thereafter only
authenticate using mechanisms of equal or higher perceived strength. Mechanism pinning A security mechanism which allows SASL clients to
resist downgrade attacks. Clients that implement mechanism
pinning remember the perceived strength of the SASL mechanism used
in a previous successful authentication attempt and thereafter
only authenticate using mechanisms of equal or higher perceived
strength.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. SASL Mechanisms 2. SASL Mechanisms
For clients and servers that support password based authentication For clients and servers that support password based authentication
using [RFC4422] it is RECOMMENDED that the following SCRAM based using SASL [RFC4422] it is RECOMMENDED that the following mechanisms
mechanisms be implemented: be implemented:
* SCRAM-SHA-256 [RFC7677] * SCRAM-SHA-256 [RFC7677]
* SCRAM-SHA-256-PLUS [RFC7677] * SCRAM-SHA-256-PLUS [RFC7677]
System entities SHOULD NOT invent their own mechanisms that have not System entities SHOULD NOT invent their own mechanisms that have not
been standardized by the IETF or another reputable standards body. been standardized by the IETF or another reputable standards body.
Similarly, entities SHOULD NOT implement any mechanism with a usage Similarly, entities SHOULD NOT implement any mechanism with a usage
status of "OBSOLETE", "MUST NOT be used", or "LIMITED" in the IANA status of "OBSOLETE", "MUST NOT be used", or "LIMITED" in the IANA
SASL Mechanisms Registry [IANA.sasl.mechanisms]. SASL Mechanisms Registry [IANA.sasl.mechanisms].
The SASL mechanisms discussed in this document do not negotiate a
security layer. Because of this a strong security layer such as TLS
[RFC8446] MUST be negotiated before SASL mechanisms can be advertised
or negotiated.
3. Client Best Practices 3. Client Best Practices
3.1. Mechanism Pinning 3.1. Mechanism Pinning
Clients often maintain a list of preferred SASL mechanisms, generally Clients often maintain a list of preferred SASL mechanisms, generally
ordered by perceived strength to enable strong authentication. To ordered by perceived strength to enable strong authentication. To
prevent downgrade attacks by a malicious actor that has successfully prevent downgrade attacks by a malicious actor that has successfully
man in the middled a connection, or compromised a trusted server's man in the middled a connection, or compromised a trusted server's
configuration, clients SHOULD implement "mechanism pinning". That configuration, clients SHOULD implement "mechanism pinning". That
is, after the first successful authentication with a strong is, after the first successful authentication with a strong
mechanism, clients SHOULD make a record of the authentication and mechanism, clients SHOULD make a record of the authentication and
thereafter only advertise and use mechanisms of equal or higher thereafter only advertise and use mechanisms of equal or higher
perceived strength. perceived strength.
For reference, the following mechanisms are ordered by their The following mechanisms are ordered by their perceived strength from
perceived strength from strongest to weakest with mechanisms of equal strongest to weakest with mechanisms of equal strength on the same
strength on the same line. This list is a non-normative example. 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 supported. should or should not be implemented.
1. EXTERNAL 1. EXTERNAL
2. SCRAM-SHA-1-PLUS, SCRAM-SHA-256-PLUS 2. SCRAM-SHA-1-PLUS, SCRAM-SHA-256-PLUS
3. SCRAM-SHA-1, SCRAM-SHA-256 3. SCRAM-SHA-1, SCRAM-SHA-256
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 it should be noted that its perceived the top of the list. However, its perceived strength depends on the
strength is equal to that of its underlying authentication protocol. underlying authentication protocol. In this example, we assume that
In this example, we assume that TLS [RFC8446] services are being used TLS [RFC8446] services are being used which can provide a strong
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 are listed above
their non-channel binding cousins, but may not always be available their non-channel binding cousins, but may not always be available
depending on the type of channel binding data available to the SASL depending on the type of channel binding data available to the SASL
negotiator. negotiator.
The PLAIN mechanism sends the username and password in plain text. The PLAIN mechanism sends the username and password in plain text,
It is therefore REQUIRED that a strong security layer such as TLS but does allow for the use of a strong key derivation function for
[RFC8446] be negotiated before using PLAIN. 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
skipping to change at page 6, line 20 skipping to change at page 6, line 27
can be easily rotated. For example, multiple peppers could be can be easily rotated. For example, multiple peppers could be
stored. New passwords and reset passwords would use the newest stored. New passwords and reset passwords would use the newest
pepper and a hash of the pepper using a cryptographically secure hash pepper and a hash of the pepper using a cryptographically secure hash
function such as SHA256 could then be stored in the database next to 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 the salt so that future logins can identify which pepper in the list
was used. This is just one example, pepper rotation schemes are was used. This is just one example, pepper rotation schemes are
outside the scope of this document. outside the scope of this document.
5. KDF Recommendations 5. KDF Recommendations
The recomendations in this section may change depending on the type When properly configured, the following commonly used KDFs create
of hardware being used and the security level required for the suitable password hash results for server side storage. The
application. With all Key Derivation Functions proper tuning is recommendations in this section may change depending on the hardware
required to ensure that it meets the needs of the specific being used and the security level required for the application.
application or service.
With all KDFs proper tuning is required to ensure that it meets the
needs of the specific application or service. For persistent login
an iteration count or work factor that adds approximately a quarter
of a second to login may be an acceptable tradeoff since logins are
relatively rare. By contrast, verification tokens that are generated
many times per second may need to use a much lower work factor.
5.1. Argon2 5.1. Argon2
Argon2 [ARGON2ESP] is a winner of the Password Hashing Competition Argon2 [ARGON2ESP] is the 2015 winner of the Password Hashing
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]. argon2 can be found in [I-D.irtf-cfrg-argon2]. They are copied here
for easier reference.
+---------------------------+--------------+
| Parameter | Value |
+===========================+==============+
| Degree of parallelism (p) | 1 |
+---------------------------+--------------+
| Memory size (m) | 32*1024 |
+---------------------------+--------------+
| Number of iterations (t) | 1 |
+---------------------------+--------------+
| Algorithm type (y) | Argon2id (2) |
+---------------------------+--------------+
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 |
+-------------------------+-------+ +-------------------------+-------+
| Maximum Password Length | 64 | | Maximum Password Length | 64 |
+-------------------------+-------+ +-------------------------+-------+
Table 2: Bcrypt Parameters Table 3: Bcrypt Parameters
5.3. PBKDF2 5.3. PBKDF2
PBKDF2 [RFC8018] is the key derivation function used by the SCRAM PBKDF2 [RFC8018] is used by the SCRAM family of SASL mechanisms.
family of SASL mechanisms.
+-----------------------+--------+ +-----------------------------+-------------------------------------+
| Parameter | Value | | Parameter | Value |
+=======================+========+ +=============================+=====================================+
| Minimum Iterations | 10,000 | | Minimum iteration count (c) | 10,000 |
+-----------------------+--------+ +-----------------------------+-------------------------------------+
| Recommended HMAC Hash | SHA256 | | Hash | SHA256 |
+-----------------------+--------+ +-----------------------------+-------------------------------------+
| Output length (dkLen) | 64 (or length of |
| | chosen hash, hLen) |
+-----------------------------+-------------------------------------+
Table 3: PBKDF2 Parameters Table 4: PBKDF2 Parameters
5.4. Scrypt 5.4. Scrypt
The [SCRYPT] key derivation function is designed to be memory-hard The [SCRYPT] KDF is designed to be memory-hard and sequential memory-
and sequential memory-hard to prevent against custom hardware based hard to prevent against custom hardware based attacks.
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) | | N | 32768 (N=2^15) |
+-----------+----------------+ +-----------+----------------+
| r | 8 | | r | 8 |
+-----------+----------------+ +-----------+----------------+
| p | 1 | | p | 1 |
+-----------+----------------+ +-----------+----------------+
Table 4: 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
using a mechanism such as PLAIN where the server performs hashing on using a mechanism such as PLAIN where the server performs hashing on
the original password, a maximum length between 64 and 128 characters the original password, a maximum length between 64 and 128 characters
skipping to change at page 8, line 33 skipping to change at page 9, line 28
keyboards output the half-width version of the same character. The keyboards output the half-width version of the same character. The
Width Mapping rule of the OpaqueString profile addresses this and Width Mapping rule of the OpaqueString profile addresses this and
ensures that comparison succeeds and the claimant is able to be ensures that comparison succeeds and the claimant is able to be
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 the [OWASP.CS.passwords]. document were taken from [OWASP.CS.passwords], [NISTSP63b], and
[NISTSP132].
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] the tls-unique and tls-server-endpoint channel
binding data does not provide enough information to uniquely identify
a session. Before advertising a channel binding SCRAM mechanism,
entities MUST ensure that the TLS extended master secret fix is in
place or that the connection has not been renegotiated.
For TLS 1.3 [RFC8446] 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.
9. IANA Considerations 9. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
10. References 10. References
10.1. Normative References 10.1. Normative References
[IANA.sasl.mechanisms] [IANA.sasl.mechanisms]
IETF, "Simple Authentication and Security Layer (SASL) IETF, "Simple Authentication and Security Layer (SASL)
Mechanisms", November 2015, Mechanisms", November 2015,
<https://www.iana.org/assignments/sasl-mechanisms/sasl- <https://www.iana.org/assignments/sasl-mechanisms/sasl-
mechanisms.xhtml>. mechanisms.xhtml>.
[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,
skipping to change at page 9, line 14 skipping to change at page 10, line 21
[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>.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
<https://www.rfc-editor.org/info/rfc5929>.
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
Langley, A., and M. Ray, "Transport Layer Security (TLS)
Session Hash and Extended Master Secret Extension",
RFC 7627, DOI 10.17487/RFC7627, September 2015,
<https://www.rfc-editor.org/info/rfc7627>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 10.2. Informative References
[ARGON2ESP] [ARGON2ESP]
Biryukov, A., Dinu, D., and D. Khovratovich, "Argon2: New Biryukov, A., Dinu, D., and D. Khovratovich, "Argon2: New
Generation of Memory-Hard Functions for Password Hashing Generation of Memory-Hard Functions for Password Hashing
and Other Applications", Euro SnP 2016, March 2016, and Other Applications", Euro SnP 2016, March 2016,
skipping to change at page 9, line 38 skipping to change at page 11, line 12
https://www.usenix.org/legacy/event/usenix99/provos/ https://www.usenix.org/legacy/event/usenix99/provos/
provos.pdf, June 1999. provos.pdf, June 1999.
[I-D.irtf-cfrg-argon2] [I-D.irtf-cfrg-argon2]
Biryukov, A., Dinu, D., Khovratovich, D., and S. Biryukov, A., Dinu, D., Khovratovich, D., and S.
Josefsson, "The memory-hard Argon2 password hash and Josefsson, "The memory-hard Argon2 password hash and
proof-of-work function", Work in Progress, Internet-Draft, proof-of-work function", Work in Progress, Internet-Draft,
draft-irtf-cfrg-argon2-10, 25 March 2020, draft-irtf-cfrg-argon2-10, 25 March 2020,
<https://tools.ietf.org/html/draft-irtf-cfrg-argon2-10>. <https://tools.ietf.org/html/draft-irtf-cfrg-argon2-10>.
[NIST.SP.800-132] [NISTSP132]
Turan, M., Barker, E., Burr, W., and L. Chen, Turan, M., Barker, E., Burr, W., and L. Chen,
"Recommendation for Password-Based Key Derivation Part 1: "Recommendation for Password-Based Key Derivation Part 1:
Storage Applications", NIST Special Publication SP Storage Applications", NIST Special Publication SP
800-132, DOI 10.6028/NIST.SP.800-132, December 2010, 800-132, DOI 10.6028/NIST.SP.800-132, December 2010,
<https://nvlpubs.nist.gov/nistpubs/Legacy/SP/ <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
nistspecialpublication800-132.pdf>. nistspecialpublication800-132.pdf>.
[NIST.SP.800-63-3] [NISTSP63-3]
Grassi, P., Garcia, M., and J. Fenton, "Digital Identity Grassi, P., Garcia, M., and J. Fenton, "Digital Identity
Guidelines", NIST Special Publication SP 800-63-3, Guidelines", NIST Special Publication SP 800-63-3,
DOI 10.6028/NIST.SP.800-63-3, June 2017, DOI 10.6028/NIST.SP.800-63-3, June 2017,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-63-3.pdf>. NIST.SP.800-63-3.pdf>.
[NIST.SP.800-63b] [NISTSP63b]
Grassi, P., Fenton, J., Newton, E., Perlner, R., Grassi, P., Fenton, J., Newton, E., Perlner, R.,
Regenscheid, A., Burr, W., Richer, J., Lefkovitz, N., Regenscheid, A., Burr, W., Richer, J., Lefkovitz, N.,
Danker, J., Choong, Y., Greene, K., and M. Theofanos, Danker, J., Choong, Y., Greene, K., and M. Theofanos,
"Digital Identity Guidelines: Authentication and Lifecycle "Digital Identity Guidelines: Authentication and Lifecycle
Management", NIST Special Publication SP 800-63b, Management", NIST Special Publication SP 800-63b,
DOI 10.6028/NIST.SP.800-63b, June 2017, DOI 10.6028/NIST.SP.800-63b, June 2017,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-63b.pdf>. NIST.SP.800-63b.pdf>.
[OWASP.CS.passwords] [OWASP.CS.passwords]
skipping to change at page 10, line 27 skipping to change at page 12, line 5
"Password Storage", OWASP Cheat Sheet Password Storage, "Password Storage", OWASP Cheat Sheet Password Storage,
April 2020, April 2020,
<https://cheatsheetseries.owasp.org/cheatsheets/ <https://cheatsheetseries.owasp.org/cheatsheets/
Password_Storage_Cheat_Sheet.html>. Password_Storage_Cheat_Sheet.html>.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422, Authentication and Security Layer (SASL)", RFC 4422,
DOI 10.17487/RFC4422, June 2006, DOI 10.17487/RFC4422, June 2006,
<https://www.rfc-editor.org/info/rfc4422>. <https://www.rfc-editor.org/info/rfc4422>.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
"Salted Challenge Response Authentication Mechanism
(SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
DOI 10.17487/RFC5802, July 2010,
<https://www.rfc-editor.org/info/rfc5802>.
[RFC6331] Melnikov, A., "Moving DIGEST-MD5 to Historic", RFC 6331, [RFC6331] Melnikov, A., "Moving DIGEST-MD5 to Historic", RFC 6331,
DOI 10.17487/RFC6331, July 2011, DOI 10.17487/RFC6331, July 2011,
<https://www.rfc-editor.org/info/rfc6331>. <https://www.rfc-editor.org/info/rfc6331>.
[RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple [RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple
Authentication and Security Layer (SASL) Mechanisms", Authentication and Security Layer (SASL) Mechanisms",
RFC 7677, DOI 10.17487/RFC7677, November 2015, RFC 7677, DOI 10.17487/RFC7677, November 2015,
<https://www.rfc-editor.org/info/rfc7677>. <https://www.rfc-editor.org/info/rfc7677>.
[RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based
skipping to change at page 11, line 22 skipping to change at page 13, line 7
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[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
U.S. executive agencies are an undervalued national treasure, so the The author would like to thank the civil servants at the National
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. Publications series. U.S. executive agencies are an undervalued
national treasure, and we should all work to protect them and the p
Thanks also to Cameron Paul for his review 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. 31 change blocks. 
71 lines changed or deleted 132 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/