Tag: Passwords

NIST Updated Guidance on Memorized Secret Verifiers (Passwords)

The National Institute of Standards and Technology recently released NIST Special Publication 800-63B: Digital Identity Guidelines, which includes updated guidance on password requirements (which NIST refers to as “memorized secret verifiers”).

The highlights include: a) not requiring users to choose new passwords based on arbitrary time limits; b) disallowing passwords that have appeared in known breaches; and c) ditching most of the silly password composition requirements (one popular service I use, for example, won’t allow you to end a password with a number).

NIST also recommends allowing users to create passwords up to 64 characters long. It would be nice to see that recommendation be widely adopted. Personally, I’m tired of banks and credit card companies that limit me to arbitrarily small passwords of 16 to 20 characters depending on the institution.

5.1.1.2 Memorized Secret Verifiers

Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length. All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets. Unicode [ISO/ISC 10646] characters SHOULD be accepted as well. To make allowances for likely mistyping, verifiers MAY replace multiple consecutive space characters with a single space character prior to verification, provided that the result is at least 8 characters in length. Truncation of the secret SHALL NOT be performed. For purposes of the above length requirements, each Unicode code point SHALL be counted as a single character.

If Unicode characters are accepted in memorized secrets, the verifier SHOULD apply the Normalization Process for Stabilized Strings using either the NFKC or NFKD normalization defined in Section 12.1 of Unicode Standard Annex 15 [UAX 15]. This process is applied before hashing the byte string representing the memorized secret. Subscribers choosing memorized secrets containing Unicode characters SHOULD be advised that some characters may be represented differently by some endpoints, which can affect their ability to authenticate successfully.

Memorized secrets that are randomly chosen by the CSP (e.g., at enrollment) or by the verifier (e.g., when a user requests a new PIN) SHALL be at least 6 characters in length and SHALL be generated using an approved random bit generator [SP 800-90Ar1].

Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant. Verifiers SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets.

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to:

Passwords obtained from previous breach corpuses.

Dictionary words.

Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).

Context-specific words, such as the name of the service, the username, and derivatives thereof.

If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value.

Verifiers SHOULD offer guidance to the subscriber, such as a password-strength meter [Meters], to assist the user in choosing a strong memorized secret. This is particularly important following the rejection of a memorized secret on the above list as it discourages trivial modification of listed (and likely very weak) memorized secrets [Blacklists].

Verifiers SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account as described in Section 5.2.2.

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets.

In order to assist the claimant in successfully entering a memorized secret, the verifier SHOULD offer an option to display the secret — rather than a series of dots or asterisks — until it is entered. This allows the claimant to verify their entry if they are in a location where their screen is unlikely to be observed. The verifier MAY also permit the user’s device to display individual entered characters for a short time after each character is typed to verify correct entry. This is particularly applicable on mobile devices.

The verifier SHALL use approved encryption and an authenticated protected channel when requesting memorized secrets in order to provide resistance to eavesdropping and MitM attacks.

Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Memorized secrets SHALL be salted and hashed using a suitable one-way key derivation function. Key derivation functions take a password, a salt, and a cost factor as inputs then generate a password hash. Their purpose is to make each password guessing trial by an attacker who has obtained a password hash file expensive and therefore the cost of a guessing attack high or prohibitive. Examples of suitable key derivation functions include Password-based Key Derivation Function 2 (PBKDF2) [SP 800-132] and Balloon [BALLOON]. A memory-hard function SHOULD be used because it increases the cost of an attack. The key derivation function SHALL use an approved one-way function such as Keyed Hash Message Authentication Code (HMAC) [FIPS 198-1], any approved hash function in SP 800-107, Secure Hash Algorithm 3 (SHA-3) [FIPS 202], CMAC [SP 800-38B] or Keccak Message Authentication Code (KMAC), Customizable SHAKE (cSHAKE), or ParallelHash [SP 800-185]. The chosen output length of the key derivation function SHOULD be the same as the length of the underlying one-way function output.

The salt SHALL be at least 32 bits in length and be chosen arbitrarily so as to minimize salt value collisions among stored hashes. Both the salt value and the resulting hash SHALL be stored for each subscriber using a memorized secret authenticator.

For PBKDF2, the cost factor is an iteration count: the more times the PBKDF2 function is iterated, the longer it takes to compute the password hash. Therefore, the iteration count SHOULD be as large as verification server performance will allow, typically at least 10,000 iterations.

In addition, verifiers SHOULD perform an additional iteration of a key derivation function using a salt value that is secret and known only to the verifier. This salt value, if used, SHALL be generated by an approved random bit generator [SP 800-90Ar1] and provide at least the minimum security strength specified in the latest revision of SP 800-131A (112 bits as of the date of this publication). The secret salt value SHALL be stored separately from the hashed memorized secrets (e.g., in a specialized device like a hardware security module). With this additional iteration, brute-force attacks on the hashed memorized secrets are impractical as long as the secret salt value remains secret.

EFF Dice-Generated Passphrases

The Electronic Frontier Foundation has its own version of DiceWare, complete with several different wordlists for randomly generating passphrases with dice.

EFF’s new long list, referenced in the directions above, is designed for memorability and passphrase strength. We recommend selecting a minimum of six words from our long wordlist, or when using any other list of this size. The more words you use, the stronger the passphrase. Different wordlists may produce passphrases with different degrees of memorability, but you don’t get a significantly different passphrase strength by using one wordlist over another, if the lists are the same length.

Personal Password Peppering/Secret Salting

A pepper or secret salt in cryptographic terms means “a secret added to an input such as a password during hashing with a cryptographic function” that is not stored with the hash itself.

Phani Karen wrote an article recently advocating using this method (which he refers to as “double-blind” and “horcruxing” for some reason) to increase the security of passwords stored in a password manager.

Karen’s recommendation goes something like this.

  1. Select an arbitrary (ideally random) short word or phrase. Let’s use kraken, for example.
  2. When you set up a password on an account, the password takes the form of password–kraken (where password is a randomly generated password or passphrase).
  3. In your password manager, you only store password.
  4. So when you revisit the site, you copy password and then manually append -kraken

The claimed advantage of doing this is that if your password manager is ever compromised, your accounts are still safe unless someone is able to guess the -kraken password stem that is not stored in the password manager.

Karan refers to this as implementing a defense in depth approach, where multiple security layers are used to mitigate damage.

I would not recommend this approach for a number of reasons.

First, it increases the pieces of information you need to know to use your password manager. Currently, I need to know my username and password to access my accounts using Bitwarden. A system like this adds a third piece of information I need to memorize.

Maybe for the intended audience, that’s not a big deal, but given how many people struggle to understand and use a password manager in the first place, anything that adds more friction to that process is to be avoided.

Second, this is exacerbated by the fact that it would likely prove difficult to keep the secret salt secret for very long.

Currently, I have about 300 accounts stored in Bitwarden, all with unique passwords. Suppose I had been adding a secret salt to my passwords for the last 5 years. In that time, about 6 of the accounts that I have were part of public breaches.

I quickly changed those passwords once I was aware of the breach. Still, if I had been using a secret salt, anyone who breached my Bitwarden account would easily be able to go back and find one of those outdated, unused passwords and quickly see a secret salt pattern in there.

The only way to guarantee my secret salt stayed secret would be to change that salt every time I was aware of a public breach, which would mean updating hundreds of uncompromised accounts, which turns my password system’s complexity up to 11.

Let Me Copy and Paste My Passwords

Occasionally I still run into sites that won’t let me copy and paste into the password field while creating an account. Or sites will let me paste into the password field but then ask me to re-enter the password for verification into a field where copying and pasting are disabled.

Developers and designers–cut this shit out.

When I create a new account, I go to my password manager and create a long random password. So I want to use a password like this:

hdER9H=~rs93(^L#;N5+B?g=

Copying and pasting such passwords is simple. Trying to type them in is an exercise in futility.

By not allowing me to copy and paste into the password field(s), you’re all but ensuring that I’m going to generate a weaker password which none of us want.

DiceKeys

DiceKeys reminds me a lot of Diceware. The user gets a set of special dice, in this case, which they roll into a box.

DiceKeys
DiceKeys

The user then closes the box, preserving their DiceKeys pattern indefinitely. The result of the dice roll is then used to seed a hash algorithm that, in turn, generates application-specific passwords and even U2F tokens.

DiceKeys
DiceKeys

DiceKeys also comes with an app that can assemble the master password automatically by scanning the dice (including their orientation, which the app uses to generate further entropy), and the QR code-like symbols on the top and bottom of the dice.

DiceKeys are backup security keys with 196 bits of security made of 25 custom dice and a rugged holder, built to last a lifetime. . . . As password managers add support for DiceKeys, you’ll also be able to use your DiceKey in place of a `master’ password. . . .

Use the open source DiceKeys app to quickly read your DiceKey from a device. Our API allows apps and services to derive their own private secrets from your DiceKey without those apps seeing the key itself.

Our reference implementation runs in most modern web browsers, allowing it to work on an incredibly diverse range of devices. While built with web-based technologies (TypeScript & WebAssembly), it runs entirely locally on your device.

We are also developing Android and iOS versions to provide a richer experience on those devices.

The cost for a set of DiceKeys looks to run about US$25.