idnits 2.17.1 draft-whited-kitten-password-storage-02.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 1430 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-02 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 . . . . . . . . . . . . . . . 6 59 5. KDF Recommendations . . . . . . . . . . . . . . . . . . . . . 6 60 5.1. Argon2 . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5.2. Bcrypt . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 5.3. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.4. Scrypt . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 6. Password Complexity Requirements . . . . . . . . . . . . . . 8 65 7. Internationalization Considerations . . . . . . . . . . . . . 9 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 10.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 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 1.1. Conventions and Terminology 84 Various security-related terms are to be understood in the sense 85 defined in [RFC4949]. Some may also be defined in [NISTSP63-3] 86 Appendix A.1 and in [NISTSP132] section 3.1. 88 Throughout this document the term "password" is used to mean any 89 password, passphrase, PIN, or other memorized secret. 91 Other common terms used throughout this document include: 93 Pepper A secret added to a password hash like a salt. Unlike a 94 salt, peppers are secret and not unique. They must not be stored 95 alongside the hashed password. 97 Mechanism pinning A security mechanism which allows SASL clients to 98 resist downgrade attacks. Clients that implement mechanism 99 pinning remember the perceived strength of the SASL mechanism used 100 in a previous successful authentication attempt and thereafter 101 only authenticate using mechanisms of equal or higher perceived 102 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 SASL [RFC4422] it is RECOMMENDED that the following mechanisms 114 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 The SASL mechanisms discussed in this document do not negotiate a 127 security layer. Because of this a strong security layer such as TLS 128 [RFC8446] MUST be negotiated before SASL mechanisms can be advertised 129 or negotiated. 131 3. Client Best Practices 133 3.1. Mechanism Pinning 135 Clients often maintain a list of preferred SASL mechanisms, generally 136 ordered by perceived strength to enable strong authentication. To 137 prevent downgrade attacks by a malicious actor that has successfully 138 man in the middled a connection, or compromised a trusted server's 139 configuration, clients SHOULD implement "mechanism pinning". That 140 is, after the first successful authentication with a strong 141 mechanism, clients SHOULD make a record of the authentication and 142 thereafter only advertise and use mechanisms of equal or higher 143 perceived strength. 145 The following mechanisms are ordered by their perceived strength from 146 strongest to weakest with mechanisms of equal strength on the same 147 line. The remainder of this section is merely informative. In 148 particular this example does not imply that mechanisms in this list 149 should or should not be implemented. 151 1. EXTERNAL 153 2. SCRAM-SHA-1-PLUS, SCRAM-SHA-256-PLUS 155 3. SCRAM-SHA-1, SCRAM-SHA-256 157 4. PLAIN 159 5. DIGEST-MD5, CRAM-MD5 161 The EXTERNAL mechanism defined in [RFC4422] appendix A is placed at 162 the top of the list. However, its perceived strength depends on the 163 underlying authentication protocol. In this example, we assume that 164 TLS [RFC8446] services are being used which can provide a strong 165 authenticator assurance level. 167 The channel binding ("-PLUS") variants of SCRAM are listed above 168 their non-channel binding cousins, but may not always be available 169 depending on the type of channel binding data available to the SASL 170 negotiator. 172 The PLAIN mechanism sends the username and password in plain text, 173 but does allow for the use of a strong key derivation function for 174 the stored version of the password on the server. 176 Finally, the DIGEST-MD5 and CRAM-MD5 mechanisms are listed last 177 because they use weak hashes and ciphers and prevent the server from 178 storing passwords using a strong key derivation function. For a list 179 of problems with DIGEST-MD5 see [RFC6331]. 181 3.2. Storage 183 Clients SHOULD always store authenticators in a trusted and encrypted 184 keystore such as the system keystore, or an encrypted store created 185 specifically for the clients use. They SHOULD NOT store 186 authenticators as plain text. 188 If clients know that they will only ever authenticate using a 189 mechanism such as SCRAM where the original password is not needed 190 after the first authentication attempt they SHOULD store the SCRAM 191 bits or the hashed and salted password instead of the original 192 password. However, if backwards compatibility with servers that only 193 support the PLAIN mechanism or other mechanisms that require using 194 the original password is required, clients MAY choose to store the 195 original password so long as an appropriate keystore is used. 197 4. Server Best Practices 199 4.1. Additional SASL Requirements 201 Servers MUST NOT support any mechanism that would require 202 authenticators to be stored in such a way that they could be 203 recovered in plain text from the stored information. This includes 204 mechanisms that store authenticators using reversable encryption, 205 obsolete hashing mechanisms such as MD5, and hashes that are 206 unsuitable for use with authenticators such as SHA256. 208 4.2. Storage 210 Servers MUST always store passwords only after they have been salted 211 and hashed. A distinct salt SHOULD be used for each user, and each 212 SCRAM family supported. Salts MUST be generated using a 213 cryptographically secure random number generator. The salt MAY be 214 stored in the same datastore as the password. If it is stored 215 alongside the password, it SHOULD be combined with a pepper stored in 216 the application configuration, an environment variable, or some other 217 location other than the datastore containing the salts. 219 The following restrictions MUST be observed when generating salts and 220 peppers: 222 +-----------------------+----------+ 223 | Parameter | Value | 224 +=======================+==========+ 225 | Minimum Salt Length | 16 bytes | 226 +-----------------------+----------+ 227 | Minimum Pepper Length | 32 bytes | 228 +-----------------------+----------+ 230 Table 1: Common Parameters 232 4.3. Authentication and Rotation 234 When authenticating using PLAIN or similar mechanisms that involve 235 transmitting the original password to the server the password MUST be 236 hashed and compared against the salted and hashed password in the 237 database using a constant time comparison. 239 Each time a password is changed a new random salt MUST be created and 240 the iteration count and pepper (if applicable) MUST be updated to the 241 latest value required by server policy. 243 If a pepper is used, consideration should be taken to ensure that it 244 can be easily rotated. For example, multiple peppers could be 245 stored. New passwords and reset passwords would use the newest 246 pepper and a hash of the pepper using a cryptographically secure hash 247 function such as SHA256 could then be stored in the database next to 248 the salt so that future logins can identify which pepper in the list 249 was used. This is just one example, pepper rotation schemes are 250 outside the scope of this document. 252 5. KDF Recommendations 254 When properly configured, the following commonly used KDFs create 255 suitable password hash results for server side storage. The 256 recommendations in this section may change depending on the hardware 257 being used and the security level required for the application. 259 With all KDFs proper tuning is required to ensure that it meets the 260 needs of the specific application or service. For persistent login 261 an iteration count or work factor that adds approximately a quarter 262 of a second to login may be an acceptable tradeoff since logins are 263 relatively rare. By contrast, verification tokens that are generated 264 many times per second may need to use a much lower work factor. 266 5.1. Argon2 268 Argon2 [ARGON2ESP] is the 2015 winner of the Password Hashing 269 Competition and has been recomended by OWASP for password hashing. 271 Security considerations, test vectors, and parameters for tuning 272 argon2 can be found in [I-D.irtf-cfrg-argon2]. They are copied here 273 for easier reference. 275 +---------------------------+--------------+ 276 | Parameter | Value | 277 +===========================+==============+ 278 | Degree of parallelism (p) | 1 | 279 +---------------------------+--------------+ 280 | Memory size (m) | 32*1024 | 281 +---------------------------+--------------+ 282 | Number of iterations (t) | 1 | 283 +---------------------------+--------------+ 284 | Algorithm type (y) | Argon2id (2) | 285 +---------------------------+--------------+ 287 Table 2: Argon Parameters 289 5.2. Bcrypt 291 bcrypt [BCRYPT] is a Blowfish-based KDF that is the current OWASP 292 recommendation for password hashing. 294 +-------------------------+-------+ 295 | Parameter | Value | 296 +=========================+=======+ 297 | Recommended Cost | 12 | 298 +-------------------------+-------+ 299 | Maximum Password Length | 64 | 300 +-------------------------+-------+ 302 Table 3: Bcrypt Parameters 304 5.3. PBKDF2 306 PBKDF2 [RFC8018] is used by the SCRAM family of SASL mechanisms. 308 +-----------------------------+-------------------------------------+ 309 | Parameter | Value | 310 +=============================+=====================================+ 311 | Minimum iteration count (c) | 10,000 | 312 +-----------------------------+-------------------------------------+ 313 | Hash | SHA256 | 314 +-----------------------------+-------------------------------------+ 315 | Output length (dkLen) | 64 (or length of | 316 | | chosen hash, hLen) | 317 +-----------------------------+-------------------------------------+ 319 Table 4: PBKDF2 Parameters 321 5.4. Scrypt 323 The [SCRYPT] KDF is designed to be memory-hard and sequential memory- 324 hard to prevent against custom hardware based attacks. 326 Security considerations, test vectors, and further notes on tuning 327 scrypt may be found in [RFC7914]. 329 +-----------+----------------+ 330 | Parameter | Value | 331 +===========+================+ 332 | N | 32768 (N=2^15) | 333 +-----------+----------------+ 334 | r | 8 | 335 +-----------+----------------+ 336 | p | 1 | 337 +-----------+----------------+ 339 Table 5: Scrypt Parameters 341 6. Password Complexity Requirements 343 Before any other password complexity requirements are checked, the 344 preparation and enforcement steps of the OpaqueString profile of 345 [RFC8265] SHOULD be applied (for more information see the 346 Internationalization Considerations section). Entities SHOULD 347 enforce a minimum length of 8 characters for user passwords. If 348 using a mechanism such as PLAIN where the server performs hashing on 349 the original password, a maximum length between 64 and 128 characters 350 MAY be imposed to prevent denial of service (DoS) attacks. Entities 351 SHOULD NOT apply any other password restrictions. 353 In addition to these password complexity requirements, servers SHOULD 354 maintain a password blacklist and reject attempts by a claimant to 355 use passwords on the blacklist during registration or password reset. 356 The contents of this blacklist are a matter of server policy. Some 357 common recommendations include lists of common passwords that are not 358 otherwise prevented by length requirements, passwords present in 359 known breaches (when paired with the same email or other uniquely 360 identifying information) to prevent reuse of compromised passwords, 361 and password that match commonly used patterns such as "any single 362 repeated character". 364 7. Internationalization Considerations 366 The PRECIS framework (Preparation, Enforcement, and Comparison of 367 Internationalized Strings) defined in [RFC8264] is used to enforce 368 internationalization rules on strings and to prevent common 369 application security issues arrising from allowing the full range of 370 Unicode codepoints in usernames, passwords, and other identifiers. 371 The OpaqueString profile of [RFC8265] is used in this document to 372 ensure that codepoints in passwords are treated carefully and 373 consistently. This ensures that users typing certain characters on 374 different keyboards that may provide different versions of the same 375 character will still be able to log in. For example, some keyboards 376 may output the full-width version of a character while other 377 keyboards output the half-width version of the same character. The 378 Width Mapping rule of the OpaqueString profile addresses this and 379 ensures that comparison succeeds and the claimant is able to be 380 authenticated. 382 8. Security Considerations 384 This document contains recommendations that are likely to change over 385 time. It should be reviewed regularly to ensure that it remains 386 accurate and up to date. Many of the recommendations in this 387 document were taken from [OWASP.CS.passwords], [NISTSP63b], and 388 [NISTSP132]. 390 The "-PLUS" variants of SCRAM support channel binding to their 391 underlying security layer, but lack a mechanism for negotiating what 392 type of channel binding to use. In [RFC5802] the tls-unique 393 [RFC5929] channel binding mechanism is specified as the default, and 394 it is therefore likely to be used in most applications that support 395 channel binding. However, in the absence of the TLS extended master 396 secret fix [RFC7627] the tls-unique and tls-server-endpoint channel 397 binding data does not provide enough information to uniquely identify 398 a session. Before advertising a channel binding SCRAM mechanism, 399 entities MUST ensure that the TLS extended master secret fix is in 400 place or that the connection has not been renegotiated. 402 For TLS 1.3 [RFC8446] no channel binding types are currently defined. 403 Channel binding SASL mechanisms MUST NOT be advertised or negotiated 404 over a TLS 1.3 channel until such types are defined. 406 9. IANA Considerations 408 This document has no actions for IANA. 410 10. References 411 10.1. Normative References 413 [IANA.sasl.mechanisms] 414 IETF, "Simple Authentication and Security Layer (SASL) 415 Mechanisms", November 2015, 416 . 419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 420 Requirement Levels", BCP 14, RFC 2119, 421 DOI 10.17487/RFC2119, March 1997, 422 . 424 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 425 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 426 . 428 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 429 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 430 . 432 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 433 Langley, A., and M. Ray, "Transport Layer Security (TLS) 434 Session Hash and Extended Master Secret Extension", 435 RFC 7627, DOI 10.17487/RFC7627, September 2015, 436 . 438 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 439 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 440 May 2017, . 442 10.2. Informative References 444 [ARGON2ESP] 445 Biryukov, A., Dinu, D., and D. Khovratovich, "Argon2: New 446 Generation of Memory-Hard Functions for Password Hashing 447 and Other Applications", Euro SnP 2016, March 2016, 448 . 450 [BCRYPT] Provos, N. and D. Mazières, "A Future-Adaptable Password 451 Scheme", USENIX 1999 452 https://www.usenix.org/legacy/event/usenix99/provos/ 453 provos.pdf, June 1999. 455 [I-D.irtf-cfrg-argon2] 456 Biryukov, A., Dinu, D., Khovratovich, D., and S. 457 Josefsson, "The memory-hard Argon2 password hash and 458 proof-of-work function", Work in Progress, Internet-Draft, 459 draft-irtf-cfrg-argon2-10, 25 March 2020, 460 . 462 [NISTSP132] 463 Turan, M., Barker, E., Burr, W., and L. Chen, 464 "Recommendation for Password-Based Key Derivation Part 1: 465 Storage Applications", NIST Special Publication SP 466 800-132, DOI 10.6028/NIST.SP.800-132, December 2010, 467 . 470 [NISTSP63-3] 471 Grassi, P., Garcia, M., and J. Fenton, "Digital Identity 472 Guidelines", NIST Special Publication SP 800-63-3, 473 DOI 10.6028/NIST.SP.800-63-3, June 2017, 474 . 477 [NISTSP63b] 478 Grassi, P., Fenton, J., Newton, E., Perlner, R., 479 Regenscheid, A., Burr, W., Richer, J., Lefkovitz, N., 480 Danker, J., Choong, Y., Greene, K., and M. Theofanos, 481 "Digital Identity Guidelines: Authentication and Lifecycle 482 Management", NIST Special Publication SP 800-63b, 483 DOI 10.6028/NIST.SP.800-63b, June 2017, 484 . 487 [OWASP.CS.passwords] 488 Manico, J., Saad, E., Maćkowski, J., and R. Bailey, 489 "Password Storage", OWASP Cheat Sheet Password Storage, 490 April 2020, 491 . 494 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 495 Authentication and Security Layer (SASL)", RFC 4422, 496 DOI 10.17487/RFC4422, June 2006, 497 . 499 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 500 "Salted Challenge Response Authentication Mechanism 501 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, 502 DOI 10.17487/RFC5802, July 2010, 503 . 505 [RFC6331] Melnikov, A., "Moving DIGEST-MD5 to Historic", RFC 6331, 506 DOI 10.17487/RFC6331, July 2011, 507 . 509 [RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple 510 Authentication and Security Layer (SASL) Mechanisms", 511 RFC 7677, DOI 10.17487/RFC7677, November 2015, 512 . 514 [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based 515 Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, 516 August 2016, . 518 [RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: 519 Password-Based Cryptography Specification Version 2.1", 520 RFC 8018, DOI 10.17487/RFC8018, January 2017, 521 . 523 [RFC8264] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: 524 Preparation, Enforcement, and Comparison of 525 Internationalized Strings in Application Protocols", 526 RFC 8264, DOI 10.17487/RFC8264, October 2017, 527 . 529 [RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, 530 Enforcement, and Comparison of Internationalized Strings 531 Representing Usernames and Passwords", RFC 8265, 532 DOI 10.17487/RFC8265, October 2017, 533 . 535 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 536 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 537 . 539 [SCRYPT] Percival, C., "Stronger key derivation via sequential 540 memory-hard functions", 541 BSDCan'09 http://www.tarsnap.com/scrypt/scrypt.pdf, May 542 2009. 544 Appendix A. Acknowledgments 546 The author would like to thank the civil servants at the National 547 Institute of Standards and Technology for their work on the Special 548 Publications series. U.S. executive agencies are an undervalued 549 national treasure, and we should all work to protect them and the p 551 Thanks also to Cameron Paul for his review and suggestions. 553 Author's Address 555 Sam Whited 556 Atlanta, GA 557 United States of America 559 Email: sam@samwhited.com 560 URI: https://blog.samwhited.com/