idnits 2.17.1 draft-whited-kitten-password-storage-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (28 April 2020) is 1459 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-irtf-cfrg-argon2-10 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Common Authentication Technology Next Generation S. Whited 3 Internet-Draft 28 April 2020 4 Intended status: Experimental 5 Expires: 30 October 2020 7 Best practices for password hashing and storage 8 draft-whited-kitten-password-storage-01 10 Abstract 12 This document outlines best practices for handling user passwords and 13 other authenticator secrets in client-server systems making use of 14 SASL. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 30 October 2020. 33 Copyright Notice 35 Copyright (c) 2020 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License text 44 as described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2 51 2. SASL Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Client Best Practices . . . . . . . . . . . . . . . . . . . . 3 53 3.1. Mechanism Pinning . . . . . . . . . . . . . . . . . . . . 3 54 3.2. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Server Best Practices . . . . . . . . . . . . . . . . . . . . 5 56 4.1. Additional SASL Requirements . . . . . . . . . . . . . . 5 57 4.2. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.3. Authentication and Rotation . . . . . . . . . . . . . . . 5 59 5. KDF Recommendations . . . . . . . . . . . . . . . . . . . . . 6 60 5.1. Argon2 . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5.2. Bcrypt . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5.3. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.4. Scrypt . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Password Complexity Requirements . . . . . . . . . . . . . . 7 65 7. Internationalization Considerations . . . . . . . . . . . . . 8 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 10.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 11 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 Following best practices when hashing and storing passwords for use 77 with SASL impacts a great deal more than just a users identity. It 78 also effects usability, backwards compatibility, and interoperability 79 by determining what authentication and authorization mechanisms can 80 be used. 82 Many of the recommendations in this document were taken from 83 [NIST.SP.800-63b] and [NIST.SP.800-132]. 85 1.1. Conventions and Terminology 87 Various security-related terms are to be understood in the sense 88 defined in [RFC4949]. Some may also be defined in [NIST.SP.800-63-3] 89 Appendix A.1 and in [NIST.SP.800-132] section 3.1. 91 Throughout this document the term "password" is used to mean any 92 password, passphrase, PIN, or other memorized secret. 94 The term "pepper" is used to mean a secret added to a password hash 95 like a salt. Unlike a salt, peppers are secret, not unique, and are 96 not stored alongside the hashed password. 98 Mechanism pinning is a security mechanism which allows SASL clients 99 to resist downgrade attacks. Clients that implement mechanism 100 pinning remember the perceived strength of the SASL mechanism used in 101 a previous successful authentication attempt and thereafter only 102 authenticate using mechanisms of equal or higher perceived strength. 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in BCP 107 14 [RFC2119] [RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 2. SASL Mechanisms 112 For clients and servers that support password based authentication 113 using [RFC4422] it is RECOMMENDED that the following SCRAM based 114 mechanisms be implemented: 116 * SCRAM-SHA-256 [RFC7677] 118 * SCRAM-SHA-256-PLUS [RFC7677] 120 System entities SHOULD NOT invent their own mechanisms that have not 121 been standardized by the IETF or another reputable standards body. 122 Similarly, entities SHOULD NOT implement any mechanism with a usage 123 status of "OBSOLETE", "MUST NOT be used", or "LIMITED" in the IANA 124 SASL Mechanisms Registry [IANA.sasl.mechanisms]. 126 3. Client Best Practices 128 3.1. Mechanism Pinning 130 Clients often maintain a list of preferred SASL mechanisms, generally 131 ordered by perceived strength to enable strong authentication. To 132 prevent downgrade attacks by a malicious actor that has successfully 133 man in the middled a connection, or compromised a trusted server's 134 configuration, clients SHOULD implement "mechanism pinning". That 135 is, after the first successful authentication with a strong 136 mechanism, clients SHOULD make a record of the authentication and 137 thereafter only advertise and use mechanisms of equal or higher 138 perceived strength. 140 For reference, the following mechanisms are ordered by their 141 perceived strength from strongest to weakest with mechanisms of equal 142 strength on the same line. This list is a non-normative example. In 143 particular this example does not imply that mechanisms in this list 144 should or should not be supported. 146 1. EXTERNAL 148 2. SCRAM-SHA-1-PLUS, SCRAM-SHA-256-PLUS 150 3. SCRAM-SHA-1, SCRAM-SHA-256 152 4. PLAIN 154 5. DIGEST-MD5, CRAM-MD5 156 The EXTERNAL mechanism defined in [RFC4422] appendix A is placed at 157 the top of the list. However it should be noted that its perceived 158 strength is equal to that of its underlying authentication protocol. 159 In this example, we assume that TLS [RFC8446] services are being used 160 which can provide a strong authenticator assurance level. 162 The channel binding ("-PLUS") variants of SCRAM are listed above 163 their non-channel binding cousins, but may not always be available 164 depending on the type of channel binding data available to the SASL 165 negotiator. 167 The PLAIN mechanism sends the username and password in plain text. 168 It is therefore REQUIRED that a strong security layer such as TLS 169 [RFC8446] be negotiated before using PLAIN. 171 Finally, the DIGEST-MD5 and CRAM-MD5 mechanisms are listed last 172 because they use weak hashes and ciphers and prevent the server from 173 storing passwords using a strong key derivation function. For a list 174 of problems with DIGEST-MD5 see [RFC6331]. 176 3.2. Storage 178 Clients SHOULD always store authenticators in a trusted and encrypted 179 keystore such as the system keystore, or an encrypted store created 180 specifically for the clients use. They SHOULD NOT store 181 authenticators as plain text. 183 If clients know that they will only ever authenticate using a 184 mechanism such as SCRAM where the original password is not needed 185 after the first authentication attempt they SHOULD store the SCRAM 186 bits or the hashed and salted password instead of the original 187 password. However, if backwards compatibility with servers that only 188 support the PLAIN mechanism or other mechanisms that require using 189 the original password is required, clients MAY choose to store the 190 original password so long as an appropriate keystore is used. 192 4. Server Best Practices 194 4.1. Additional SASL Requirements 196 Servers MUST NOT support any mechanism that would require 197 authenticators to be stored in such a way that they could be 198 recovered in plain text from the stored information. This includes 199 mechanisms that store authenticators using reversable encryption, 200 obsolete hashing mechanisms such as MD5, and hashes that are 201 unsuitable for use with authenticators such as SHA256. 203 4.2. Storage 205 Servers MUST always store passwords only after they have been salted 206 and hashed. A distinct salt SHOULD be used for each user, and each 207 SCRAM family supported. Salts MUST be generated using a 208 cryptographically secure random number generator. The salt MAY be 209 stored in the same datastore as the password. If it is stored 210 alongside the password, it SHOULD be combined with a pepper stored in 211 the application configuration, an environment variable, or some other 212 location other than the datastore containing the salts. 214 The following restrictions MUST be observed when generating salts and 215 peppers: 217 +-----------------------+----------+ 218 | Parameter | Value | 219 +=======================+==========+ 220 | Minimum Salt Length | 16 bytes | 221 +-----------------------+----------+ 222 | Minimum Pepper Length | 32 bytes | 223 +-----------------------+----------+ 225 Table 1: Common Parameters 227 4.3. Authentication and Rotation 229 When authenticating using PLAIN or similar mechanisms that involve 230 transmitting the original password to the server the password MUST be 231 hashed and compared against the salted and hashed password in the 232 database using a constant time comparison. 234 Each time a password is changed a new random salt MUST be created and 235 the iteration count and pepper (if applicable) MUST be updated to the 236 latest value required by server policy. 238 If a pepper is used, consideration should be taken to ensure that it 239 can be easily rotated. For example, multiple peppers could be 240 stored. New passwords and reset passwords would use the newest 241 pepper and a hash of the pepper using a cryptographically secure hash 242 function such as SHA256 could then be stored in the database next to 243 the salt so that future logins can identify which pepper in the list 244 was used. This is just one example, pepper rotation schemes are 245 outside the scope of this document. 247 5. KDF Recommendations 249 The recomendations in this section may change depending on the type 250 of hardware being used and the security level required for the 251 application. With all Key Derivation Functions proper tuning is 252 required to ensure that it meets the needs of the specific 253 application or service. 255 5.1. Argon2 257 Argon2 [ARGON2ESP] is a winner of the Password Hashing Competition 258 and has been recomended by OWASP for password hashing. 260 Security considerations, test vectors, and parameters for tuning 261 argon2 can be found in [I-D.irtf-cfrg-argon2]. 263 5.2. Bcrypt 265 bcrypt [BCRYPT] is a Blowfish-based KDF that is the current OWASP 266 recommendation for password hashing. 268 +-------------------------+-------+ 269 | Parameter | Value | 270 +=========================+=======+ 271 | Recommended Cost | 12 | 272 +-------------------------+-------+ 273 | Maximum Password Length | 64 | 274 +-------------------------+-------+ 276 Table 2: Bcrypt Parameters 278 5.3. PBKDF2 280 PBKDF2 [RFC8018] is the key derivation function used by the SCRAM 281 family of SASL mechanisms. 283 +-----------------------+--------+ 284 | Parameter | Value | 285 +=======================+========+ 286 | Minimum Iterations | 10,000 | 287 +-----------------------+--------+ 288 | Recommended HMAC Hash | SHA256 | 289 +-----------------------+--------+ 291 Table 3: PBKDF2 Parameters 293 5.4. Scrypt 295 The [SCRYPT] key derivation function is designed to be memory-hard 296 and sequential memory-hard to prevent against custom hardware based 297 attacks. 299 Security considerations, test vectors, and further notes on tuning 300 scrypt may be found in [RFC7914]. 302 +-----------+----------------+ 303 | Parameter | Value | 304 +===========+================+ 305 | N | 32768 (N=2^15) | 306 +-----------+----------------+ 307 | r | 8 | 308 +-----------+----------------+ 309 | p | 1 | 310 +-----------+----------------+ 312 Table 4: Scrypt Parameters 314 6. Password Complexity Requirements 316 Before any other password complexity requirements are checked, the 317 preparation and enforcement steps of the OpaqueString profile of 318 [RFC8265] SHOULD be applied (for more information see the 319 Internationalization Considerations section). Entities SHOULD 320 enforce a minimum length of 8 characters for user passwords. If 321 using a mechanism such as PLAIN where the server performs hashing on 322 the original password, a maximum length between 64 and 128 characters 323 MAY be imposed to prevent denial of service (DoS) attacks. Entities 324 SHOULD NOT apply any other password restrictions. 326 In addition to these password complexity requirements, servers SHOULD 327 maintain a password blacklist and reject attempts by a claimant to 328 use passwords on the blacklist during registration or password reset. 329 The contents of this blacklist are a matter of server policy. Some 330 common recommendations include lists of common passwords that are not 331 otherwise prevented by length requirements, passwords present in 332 known breaches (when paired with the same email or other uniquely 333 identifying information) to prevent reuse of compromised passwords, 334 and password that match commonly used patterns such as "any single 335 repeated character". 337 7. Internationalization Considerations 339 The PRECIS framework (Preparation, Enforcement, and Comparison of 340 Internationalized Strings) defined in [RFC8264] is used to enforce 341 internationalization rules on strings and to prevent common 342 application security issues arrising from allowing the full range of 343 Unicode codepoints in usernames, passwords, and other identifiers. 344 The OpaqueString profile of [RFC8265] is used in this document to 345 ensure that codepoints in passwords are treated carefully and 346 consistently. This ensures that users typing certain characters on 347 different keyboards that may provide different versions of the same 348 character will still be able to log in. For example, some keyboards 349 may output the full-width version of a character while other 350 keyboards output the half-width version of the same character. The 351 Width Mapping rule of the OpaqueString profile addresses this and 352 ensures that comparison succeeds and the claimant is able to be 353 authenticated. 355 8. Security Considerations 357 This document contains recommendations that are likely to change over 358 time. It should be reviewed regularly to ensure that it remains 359 accurate and up to date. Many of the recommendations in this 360 document were taken from the [OWASP.CS.passwords]. 362 9. IANA Considerations 364 This document has no actions for IANA. 366 10. References 368 10.1. Normative References 370 [IANA.sasl.mechanisms] 371 IETF, "Simple Authentication and Security Layer (SASL) 372 Mechanisms", November 2015, 373 . 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, 378 DOI 10.17487/RFC2119, March 1997, 379 . 381 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 382 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 383 . 385 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 386 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 387 May 2017, . 389 10.2. Informative References 391 [ARGON2ESP] 392 Biryukov, A., Dinu, D., and D. Khovratovich, "Argon2: New 393 Generation of Memory-Hard Functions for Password Hashing 394 and Other Applications", Euro SnP 2016, March 2016, 395 . 397 [BCRYPT] Provos, N. and D. Mazières, "A Future-Adaptable Password 398 Scheme", USENIX 1999 399 https://www.usenix.org/legacy/event/usenix99/provos/ 400 provos.pdf, June 1999. 402 [I-D.irtf-cfrg-argon2] 403 Biryukov, A., Dinu, D., Khovratovich, D., and S. 404 Josefsson, "The memory-hard Argon2 password hash and 405 proof-of-work function", Work in Progress, Internet-Draft, 406 draft-irtf-cfrg-argon2-10, 25 March 2020, 407 . 409 [NIST.SP.800-132] 410 Turan, M., Barker, E., Burr, W., and L. Chen, 411 "Recommendation for Password-Based Key Derivation Part 1: 412 Storage Applications", NIST Special Publication SP 413 800-132, DOI 10.6028/NIST.SP.800-132, December 2010, 414 . 417 [NIST.SP.800-63-3] 418 Grassi, P., Garcia, M., and J. Fenton, "Digital Identity 419 Guidelines", NIST Special Publication SP 800-63-3, 420 DOI 10.6028/NIST.SP.800-63-3, June 2017, 421 . 424 [NIST.SP.800-63b] 425 Grassi, P., Fenton, J., Newton, E., Perlner, R., 426 Regenscheid, A., Burr, W., Richer, J., Lefkovitz, N., 427 Danker, J., Choong, Y., Greene, K., and M. Theofanos, 428 "Digital Identity Guidelines: Authentication and Lifecycle 429 Management", NIST Special Publication SP 800-63b, 430 DOI 10.6028/NIST.SP.800-63b, June 2017, 431 . 434 [OWASP.CS.passwords] 435 Manico, J., Saad, E., Maćkowski, J., and R. Bailey, 436 "Password Storage", OWASP Cheat Sheet Password Storage, 437 April 2020, 438 . 441 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 442 Authentication and Security Layer (SASL)", RFC 4422, 443 DOI 10.17487/RFC4422, June 2006, 444 . 446 [RFC6331] Melnikov, A., "Moving DIGEST-MD5 to Historic", RFC 6331, 447 DOI 10.17487/RFC6331, July 2011, 448 . 450 [RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple 451 Authentication and Security Layer (SASL) Mechanisms", 452 RFC 7677, DOI 10.17487/RFC7677, November 2015, 453 . 455 [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based 456 Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, 457 August 2016, . 459 [RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: 460 Password-Based Cryptography Specification Version 2.1", 461 RFC 8018, DOI 10.17487/RFC8018, January 2017, 462 . 464 [RFC8264] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: 465 Preparation, Enforcement, and Comparison of 466 Internationalized Strings in Application Protocols", 467 RFC 8264, DOI 10.17487/RFC8264, October 2017, 468 . 470 [RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, 471 Enforcement, and Comparison of Internationalized Strings 472 Representing Usernames and Passwords", RFC 8265, 473 DOI 10.17487/RFC8265, October 2017, 474 . 476 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 477 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 478 . 480 [SCRYPT] Percival, C., "Stronger key derivation via sequential 481 memory-hard functions", 482 BSDCan'09 http://www.tarsnap.com/scrypt/scrypt.pdf, May 483 2009. 485 Appendix A. Acknowledgments 487 U.S. executive agencies are an undervalued national treasure, so the 488 author would like to thank the civil servants at the National 489 Institute of Standards and Technology for their work on the Special 490 Publications series. 492 Author's Address 494 Sam Whited 495 Atlanta, GA 496 United States of America 498 Email: sam@samwhited.com 499 URI: https://blog.samwhited.com/