{"id":28252,"date":"2024-11-06T21:58:18","date_gmt":"2024-11-06T16:28:18","guid":{"rendered":"https:\/\/www.kaspersky.co.in\/blog\/2024-password-and-otp-requirements-nist-sp-800-63\/28252\/"},"modified":"2024-11-06T21:58:18","modified_gmt":"2024-11-06T16:28:18","slug":"2024-password-and-otp-requirements-nist-sp-800-63","status":"publish","type":"post","link":"https:\/\/www.kaspersky.co.in\/blog\/2024-password-and-otp-requirements-nist-sp-800-63\/28252\/","title":{"rendered":"Password standards: 2024 requirements"},"content":{"rendered":"<p>The requirements set by online services for user verification \u2014 whether it\u2019s password length, a mandatory phone number, or biometric checks with blinking \u2014 are often governed by industry standards. One of the most important documents in this field are the <a href=\"https:\/\/pages.nist.gov\/800-63-4\/\" target=\"_blank\" rel=\"nofollow noopener\">NIST SP 800-63<\/a> Digital Identity Guidelines, developed by the US National Institute of Standards and Technology (NIST). This standard is mandatory for all US government agencies and their contractors; in practice, this means that all the world\u2019s largest IT companies adhere to this standard, with consequences reaching far beyond the borders of the United States.<\/p>\n<p>Even organizations that aren\u2019t strictly required to comply with NIST SP 800-63 would still benefit from familiarizing themselves with these updated guidelines, as they often serve as a blueprint for regulators in other countries and industries. The recent update, developed through four rounds of public revisions with industry experts, reflects the latest understanding of digital identification and authentication. It covers security and privacy requirements, and considers a possible distributed (federated) approach. The standard is practical, and factors in human considerations \u2014 how users respond to various authentication requirements.<\/p>\n<p>This new edition formalizes concepts, and outlines requirements for:<\/p>\n<ul>\n<li><a href=\"https:\/\/www.kaspersky.com\/blog\/how-to-set-up-passkeys-in-google-account\/49515\/\" target=\"_blank\" rel=\"noopener nofollow\">passkeys<\/a> (referred to in the standard as \u201csyncable authenticators\u201d);<\/li>\n<li>phishing-resistant authentication;<\/li>\n<li>user storage of passwords and accesses (\u201cattribute bundles\u201d);<\/li>\n<li>regular re-authentication;<\/li>\n<li>session tokens.<\/li>\n<\/ul>\n<p>So \u2014 how to authenticate users in 2024?<\/p>\n<h2>Password authentication<\/h2>\n<p>The standard defines three Authentication Assurance Levels (AALs). AAL1 allows the least restrictions and minimal confidence that the user is indeed who they claim to be, while AAL3 offers the strongest guarantees and requires more stringent authentication. Only AAL1 permits single-factor authentication \u2014 such as just a single password.<\/p>\n<p>The requirements for passwords are as follows:<\/p>\n<ul>\n<li>Only centrally verified secrets sent by the user to the server over a secure channel qualify as passwords. Passwords that are stored and verified locally are termed \u201cactivation secrets\u201d and have different requirements.<\/li>\n<li>Passwords shorter than eight characters are prohibited, with a minimum of 15 characters recommended.<\/li>\n<li>Scheduled, mandatory password rotation is considered an outdated practice and therefore prohibited.<\/li>\n<li>It\u2019s also prohibited to impose requirements on password composition (such as \u201cyour password must contain a letter, a number, and a symbol\u201d).<\/li>\n<li>It\u2019s recommended to allow using any visible ASCII characters, spaces, and most Unicode symbols (such as emojis).<\/li>\n<li>Maximum password length, if enforced, must be at least 64 characters.<\/li>\n<li>Truncating passwords during verification is prohibited, but trimming leading\/trailing whitespace is allowed if it interferes with authentication.<\/li>\n<li>Using and storing password hints or security questions (such as \u201cyour mother\u2019s maiden name\u201d) is prohibited.<\/li>\n<li>Commonly used passwords must be eliminated through the use of a stop-list of popular or leaked passwords.<\/li>\n<li>Compromised passwords (for example, appearing in data breaches) must be reset immediately.<\/li>\n<li>Login attempts must be limited in both rate and number of unsuccessful attempts.<\/li>\n<\/ul>\n<h2>Activation secrets<\/h2>\n<p>These are PINs and local passwords that restrict access to the on-device key storage. They can be numeric, with a recommended minimum length of six digits\u2014 though four digits are permissible. For AAL3, the primary cryptographic secret (for example, a passkey) must be stored in a tamper-resistant chip, and decrypted using the activation secret. For AAL1 and AAL2, it\u2019s enough that the key restricts access from outsiders, with a limit on input attempts \u2014 no more than 10 tries. After exceeding the limit, the storage is locked, requiring an alternative authentication method.<\/p>\n<h2>Multi-factor authentication (MFA)<\/h2>\n<p>It\u2019s recommended to <a href=\"https:\/\/www.kaspersky.com\/blog\/2fa-practical-guide\/24219\/\" target=\"_blank\" rel=\"noopener nofollow\">implement MFA<\/a> at all AAL levels, but while this is only a suggestion for AAL1, it\u2019s mandatory for AAL2, and only phishing-resistant MFA methods are acceptable for AAL3.<\/p>\n<p>Only cryptographic authentication methods are considered phishing-resistant: USB tokens, passkeys, and cryptographic keys stored in digital wallets conforming to SP 800-63C (distributed identification and authentication services). All cryptographic secrets must be stored in tamper-resistant systems (such as TPM or Secure Enclave). Synchronizing keys across devices and storing them in the cloud is permitted, provided each device meets the standard\u2019s requirements. These provisions enable the use of passkeys across Android and iOS ecosystems.<\/p>\n<p>To ensure resistance to phishing, authentication must be tied to the communication channel (channel binding) or verifier service name (verifier name binding). Examples of these approaches include client-authenticated TLS connections and the WebAuthn protocol from the <a href=\"https:\/\/www.kaspersky.com\/blog\/passkey-future-without-passwords\/44418\/\" target=\"_blank\" rel=\"noopener nofollow\">FIDO2<\/a> specification. In simple terms, the client uses cryptography to confirm they\u2019re connecting with the legitimate server rather than a fake one set up for <a href=\"https:\/\/www.kaspersky.com\/blog\/what-is-aitm-in-spearphishing-attacks\/51919\/\" target=\"_blank\" rel=\"noopener nofollow\">AitM attacks<\/a>.<\/p>\n<p>Time-based one-time passwords (TOTP) from authenticator apps, SMS codes, and one-time codes from scratch cards or envelopes are not phishing-resistant but are permitted for AAL1 and AAL2 services. The standard specifies which methods for handling one-time codes don\u2019t qualify as MFA and must be avoided. One-time codes should not be sent through email or VoIP \u2014 they must be delivered over a communication channel that\u2019s separate from the primary authentication process. OTPs sent through SMS and traditional telephone lines are acceptable \u2014 even if both connections (for example, internet and SMS) are on the same device.<\/p>\n<h2>Use of biometrics<\/h2>\n<p>The standard restricts the use of biometrics \u2014 they may serve as an authentication factor, but are prohibited for identification. Biometric checks must be used only as a supplemental factor combined with proof of possession (for example, a smartphone or token \u2014 something you physically possess).<\/p>\n<p>Biometric equipment and algorithms must ensure a false match rate (FMR) no greater than 1 in 10,000, and a false non-match rate (FNMR) no greater than 5%. These accuracy rates must be consistent across all demographics. The verification algorithm must also be resistant to presentation attacks in which the sensor is shown a photo or video instead of a live person.<\/p>\n<p>After generating and verifying a cryptographic \u201cfingerprint\u201d from biometric data, the standard mandates immediate deletion (zeroing out) of collected biometric data.<\/p>\n<p>Like other authentication methods, biometric checks must include limits on input rate and the number of unsuccessful attempts.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Discontinuing mandatory password rotations, banning outdated MFA methods, and other updates in the NIST SP 800-63 standards for digital account authentication and management.<\/p>\n","protected":false},"author":2722,"featured_media":28253,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2036,2609],"tags":[1181,359,2052,1365,3097,187,43,321,1898],"class_list":{"0":"post-28252","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"tag-2fa","10":"tag-authentication","11":"tag-business","12":"tag-identity","13":"tag-mfa","14":"tag-passwords","15":"tag-privacy","16":"tag-technology","17":"tag-tips"},"hreflang":[{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/2024-password-and-otp-requirements-nist-sp-800-63\/28252\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/2024-password-and-otp-requirements-nist-sp-800-63\/23504\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/2024-password-and-otp-requirements-nist-sp-800-63\/30644\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/2024-password-and-otp-requirements-nist-sp-800-63\/28388\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/2024-password-and-otp-requirements-nist-sp-800-63\/38475\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/2024-password-and-otp-requirements-nist-sp-800-63\/52544\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/2024-password-and-otp-requirements-nist-sp-800-63\/28450\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/2024-password-and-otp-requirements-nist-sp-800-63\/34344\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/2024-password-and-otp-requirements-nist-sp-800-63\/33969\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.co.in\/blog\/tag\/passwords\/","name":"passwords"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.co.in\/blog\/wp-json\/wp\/v2\/posts\/28252","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.co.in\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.co.in\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.co.in\/blog\/wp-json\/wp\/v2\/users\/2722"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.co.in\/blog\/wp-json\/wp\/v2\/comments?post=28252"}],"version-history":[{"count":0,"href":"https:\/\/www.kaspersky.co.in\/blog\/wp-json\/wp\/v2\/posts\/28252\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.co.in\/blog\/wp-json\/wp\/v2\/media\/28253"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.co.in\/blog\/wp-json\/wp\/v2\/media?parent=28252"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.co.in\/blog\/wp-json\/wp\/v2\/categories?post=28252"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.co.in\/blog\/wp-json\/wp\/v2\/tags?post=28252"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}