idnits 2.17.1 draft-whited-kitten-password-storage-00.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 (21 April 2020) is 1465 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 21 April 2020 4 Intended status: Experimental 5 Expires: 23 October 2020 7 Best practices for password hashing and storage 8 draft-whited-kitten-password-storage-00 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 23 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 . . . . . . . . . . . . . . . . . . . . 4 56 4.1. Additional SASL Requirements . . . . . . . . . . . . . . 4 57 4.2. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.3. Authentication and Rotation . . . . . . . . . . . . . . . 5 59 5. KDF Recommendations . . . . . . . . . . . . . . . . . . . . . 5 60 5.1. Argon2 . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5.2. Bcrypt . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 5.3. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.4. Scrypt . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Password Complexity Requirements . . . . . . . . . . . . . . 7 65 7. Internationalization Considerations . . . . . . . . . . . . . 7 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 10.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 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, and backwards compatibility by determining 79 what authentication and authorization mechanisms can be used. 81 Many of the recommendations in this document were taken from 82 [NIST.SP.800-63b] and [NIST.SP.800-132]. 84 1.1. Conventions and Terminology 86 Various security-related terms are to be understood in the sense 87 defined in [RFC4949]. Some may also be defined in [NIST.SP.800-63-3] 88 Appendix A.1 and in [NIST.SP.800-132] section 3.1. 90 Throughout this document the term "password" is used to mean any 91 password, passphrase, PIN, or other memorized secret. 93 The term "pepper" is used to mean a secret added to a password hash 94 like a salt. Unlike a salt, peppers are secret, not unique, and are 95 not stored alongside the hashed password. 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 2. SASL Mechanisms 105 For clients and servers that support password based authentication 106 using [RFC4422] it is RECOMMENDED that the following SCRAM based 107 mechanisms be implemented: 109 * SCRAM-SHA-256 ([RFC7677]) 111 * SCRAM-SHA-256-PLUS ([RFC7677]) 113 System entities SHOULD NOT invent their own mechanisms that have not 114 been standardized by the IETF or another reputable standards body. 115 Similarly, entities SHOULD NOT implement any mechanism with a usage 116 status of "OBSOLETE", "MUST NOT be used", or "LIMITED" in the IANA 117 SASL Mechanisms Registry [IANA.sasl.mechanisms]. 119 3. Client Best Practices 121 3.1. Mechanism Pinning 123 Clients often maintain a list of preferred SASL mechanisms, generally 124 ordered by perceived strength to enable strong authentication. To 125 prevent downgrade attacks by a malicious actor that has successfully 126 man in the middled a connection, or compromised a trusted server's 127 configuration, clients SHOULD implement "mechanism pinning". That 128 is, after the first successful authentication with a strong 129 mechanism, clients SHOULD make a record of the authentication and 130 thereafter only advertise and use mechanisms of equal or higher 131 perceived strength. 133 For reference, the following mechanisms are ordered by their 134 perceived strength from strongest to weakest with mechanisms of equal 135 strength on the same line. This list is a non-normative example. In 136 particular this example does not imply that mechanisms in this list 137 should or should not be supported. 139 1. EXTERNAL 140 2. SCRAM-SHA-1-PLUS, SCRAM-SHA-256-PLUS 142 3. SCRAM-SHA-1, SCRAM-SHA-256 144 4. PLAIN 146 5. DIGEST-MD5, CRAM-MD5 148 3.2. Storage 150 Clients SHOULD always store authenticators in a trusted and encrypted 151 keystore such as the system keystore, or an encrypted store created 152 specifically for the clients use. They SHOULD NOT store 153 authenticators as plain text. 155 If clients know that they will only ever authenticate using a 156 mechanism such as SCRAM where the original password is not needed 157 (for example if the mechanism has been pinned) they SHOULD store the 158 SCRAM bits or the hashed and salted password instead of the original 159 password. However, if backwards compatibility with servers that only 160 support the PLAIN mechanism or other mechanisms that require using 161 the original password is required, clients MAY choose to store the 162 original password so long as an appropriate keystore is used. 164 4. Server Best Practices 166 4.1. Additional SASL Requirements 168 Servers MUST NOT support any mechanism that would require 169 authenticators to be stored in such a way that they could be 170 recovered in plain text from the stored information. This includes 171 mechanisms that store authenticators using reversable encryption, 172 obsolete hashing mechanisms such as MD5, and hashes that are 173 unsuitable for use with authenticators such as SHA256. 175 4.2. Storage 177 Servers MUST always store passwords only after they have been salted 178 and hashed. If multiple hashes are supported for use with SCRAM, for 179 example SCRAM-SHA-1 and SCRAM-SHA-256, separate salted and hashed 180 passwords SHOULD be calculated and stored for each mechanism so that 181 multiple clients that support only some of the mechanisms. 183 A distinct salt SHOULD be used for each user, and each SCRAM family 184 supported. Salts MUST be generated using a cryptographically secure 185 random number generator. The salt MAY be stored in the same 186 datastore as the password. If it is stored alongside the password, 187 it SHOULD be combined with a pepper stored in the application 188 configuration, an environment variable, or some other location other 189 than the datastore containing the salts. 191 4.3. Authentication and Rotation 193 When authenticating using PLAIN or similar mechanisms that involve 194 transmitting the original password to the server the password MUST be 195 hashed and compared against the salted and hashed password in the 196 database using a constant time comparison. 198 Each time a password is changed or reset, a new random salt MUST be 199 created and the iteration count and pepper (if applicable) MUST be 200 updated to the latest value required by server policy. 202 If a pepper is used, consideration should be taken to ensure that it 203 can be easily rotated. For example, multiple peppers could be 204 stored. New passwords and reset passwords would use the newest 205 papper and a hash of the pepper using a cryptographically secure hash 206 function such as SHA256 could then be stored in the database next to 207 the salt so that future logins can identify which pepper in the list 208 was used. This is just one example, pepper rotation schemes are 209 outside the scope of this document. 211 5. KDF Recommendations 213 The recomendations in this section may change depending on the type 214 of hardware being used and the security level required for the 215 application. With all Key Derivation Functions proper tuning is 216 required to ensure that it meets the neds of the specific application 217 or service. 219 5.1. Argon2 221 Argon2 [ARGON2ESP] is a winner of the Password Hashing Competition 222 and has been recomended by OWASP for password hashing. 224 Security considerations, test vectors, and parameters for tuning 225 argon2 can be found in [I-D.irtf-cfrg-argon2]. 227 5.2. Bcrypt 229 bcrypt [BCRYPT] is a Blowfish-based KDF that is the current OWASP 230 recommendation for password hashing. 232 +-------------------------+-------+ 233 | Parameter | Value | 234 +=========================+=======+ 235 | Recommended Cost | 12 | 236 +-------------------------+-------+ 237 | Maximum Password Length | 64 | 238 +-------------------------+-------+ 240 Table 1: Bcrypt Parameters 242 5.3. PBKDF2 244 PBKDF2 [RFC8018] is the key derivation function used by the SCRAM 245 family of SASL mechanisms. 247 +-----------------------+----------+ 248 | Parameter | Value | 249 +=======================+==========+ 250 | Minimum Iterations | 10,000 | 251 +-----------------------+----------+ 252 | Minimum Salt Length | 16 bytes | 253 +-----------------------+----------+ 254 | Minimum Pepper Length | 32 bytes | 255 +-----------------------+----------+ 257 Table 2: PBKDF2 Parameters 259 5.4. Scrypt 261 The [SCRYPT] key derivation function is designed to be memory-hard 262 and sequential memory-hard to prevent against custom hardware based 263 attacks. 265 Security considerations, test vectors, and further notes on tuning 266 scrypt may be found in [RFC7914]. 268 +-----------+----------------+ 269 | Parameter | Value | 270 +===========+================+ 271 | N | 32768 (N=2^15) | 272 +-----------+----------------+ 273 | r | 8 | 274 +-----------+----------------+ 275 | p | 1 | 276 +-----------+----------------+ 278 Table 3: Scrypt Parameters 280 6. Password Complexity Requirements 282 Before any other password complexity requirements are checked, the 283 preparation and enforcement steps of the OpaqueString profile of 284 [RFC8265] SHOULD be applied (for more information see the 285 Internationalization Considerations section). Entities SHOULD 286 enforce a minimum length of 8 characters for user passwords. If 287 using a mechanism such as PLAIN where the server performs hashing on 288 the original password, a maximum length between 64 and 128 characters 289 MAY be imposed to prevent denial of service (DoS) attacks. Entities 290 SHOULD NOT apply any other password restrictions. 292 In addition to these password complexity requirements, servers SHOULD 293 maintain a password blacklist and reject attempts by a claimant to 294 use passwords on the blacklist during registration or password reset. 295 The contents of this blacklist are a matter of server policy. Some 296 common recommendations include lists of common passwords that are not 297 otherwise prevented by length requirements, passwords present in 298 known breaches (when paired with the same email or other uniquely 299 identifying information) to prevent reuse of compromised passwords, 300 and password that match commonly used patterns such as "any single 301 repeated character". 303 7. Internationalization Considerations 305 The PRECIS framework (Preparation, Enforcement, and Comparison of 306 Internationalized Strings) defined in [RFC8264] is used to enforce 307 internationalization rules on strings and to prevent common 308 application security issues arrising from allowing the full range of 309 Unicode codepoints in usernames, passwords, and other identifiers. 310 The OpaqueString profile of [RFC8265] is used in this document to 311 ensure that codepoints in passwords are treated carefully and 312 consistently. This ensures that users typing certain characters on 313 different keyboards that may provide different versions of the same 314 character will still be able to log in. For example, some keyboards 315 may output the full-width version of a character while other 316 keyboards output the half-width version of the same character. The 317 Width Mapping rule of the OpaqueString profile addresses this and 318 ensures that comparison succeeds and the claimant is able to be 319 authenticated. 321 8. Security Considerations 323 This document contains recommendations that are likely to change over 324 time. It should be reviewed regularly to ensure that it remains 325 accurate and up to date. Many of the recommendations in this 326 document were taken from the [OWASP.CS.passwords]. 328 9. IANA Considerations 330 This document has no actions for IANA. 332 10. References 334 10.1. Normative References 336 [IANA.sasl.mechanisms] 337 IETF, "Simple Authentication and Security Layer (SASL) 338 Mechanisms", November 2015, 339 . 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, 344 DOI 10.17487/RFC2119, March 1997, 345 . 347 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 348 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 349 . 351 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 352 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 353 May 2017, . 355 10.2. Informative References 357 [ARGON2ESP] 358 Biryukov, A., Dinu, D., and D. Khovratovich, "Argon2: New 359 Generation of Memory-Hard Functions for Password Hashing 360 and Other Applications", Euro SnP 2016, March 2016, 361 . 363 [BCRYPT] Provos, N. and D. Mazières, "A Future-Adaptable Password 364 Scheme", USENIX 1999 365 https://www.usenix.org/legacy/event/usenix99/provos/ 366 provos.pdf, June 1999. 368 [I-D.irtf-cfrg-argon2] 369 Biryukov, A., Dinu, D., Khovratovich, D., and S. 370 Josefsson, "The memory-hard Argon2 password hash and 371 proof-of-work function", Work in Progress, Internet-Draft, 372 draft-irtf-cfrg-argon2-10, 25 March 2020, 373 . 375 [NIST.SP.800-132] 376 Turan, M., Barker, E., Burr, W., and L. Chen, 377 "Recommendation for Password-Based Key Derivation Part 1: 378 Storage Applications", NIST Special Publication SP 379 800-132, DOI 10.6028/NIST.SP.800-132, December 2010, 380 . 383 [NIST.SP.800-63-3] 384 Grassi, P., Garcia, M., and J. Fenton, "Digital Identity 385 Guidelines", NIST Special Publication SP 800-63-3, 386 DOI 10.6028/NIST.SP.800-63-3, June 2017, 387 . 390 [NIST.SP.800-63b] 391 Grassi, P., Fenton, J., Newton, E., Perlner, R., 392 Regenscheid, A., Burr, W., Richer, J., Lefkovitz, N., 393 Danker, J., Choong, Y., Greene, K., and M. Theofanos, 394 "Digital Identity Guidelines: Authentication and Lifecycle 395 Management", NIST Special Publication SP 800-63b, 396 DOI 10.6028/NIST.SP.800-63b, June 2017, 397 . 400 [OWASP.CS.passwords] 401 Manico, J., Saad, E., Maćkowski, J., and R. Bailey, 402 "Password Storage", OWASP Cheat Sheet Password Storage, 403 April 2020, 404 . 407 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 408 Authentication and Security Layer (SASL)", RFC 4422, 409 DOI 10.17487/RFC4422, June 2006, 410 . 412 [RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple 413 Authentication and Security Layer (SASL) Mechanisms", 414 RFC 7677, DOI 10.17487/RFC7677, November 2015, 415 . 417 [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based 418 Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, 419 August 2016, . 421 [RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: 422 Password-Based Cryptography Specification Version 2.1", 423 RFC 8018, DOI 10.17487/RFC8018, January 2017, 424 . 426 [RFC8264] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: 427 Preparation, Enforcement, and Comparison of 428 Internationalized Strings in Application Protocols", 429 RFC 8264, DOI 10.17487/RFC8264, October 2017, 430 . 432 [RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, 433 Enforcement, and Comparison of Internationalized Strings 434 Representing Usernames and Passwords", RFC 8265, 435 DOI 10.17487/RFC8265, October 2017, 436 . 438 [SCRYPT] Percival, C., "Stronger key derivation via sequential 439 memory-hard functions", 440 BSDCan'09 http://www.tarsnap.com/scrypt/scrypt.pdf, May 441 2009. 443 Appendix A. Acknowledgments 445 U.S. executive agencies are an undervalued national treasure, so the 446 author would like to thank the civil servants at the National 447 Institute of Standards and Technology for their work on the Special 448 Publications series. 450 Author's Address 452 Sam Whited 453 Atlanta, GA 454 United States of America 456 Email: sam@samwhited.com