NIST Recommends Some Common-Sense Password Rules

NIST’s second draft of its “SP 800-63-4“—its digital identify guidelines—finally contains some really good rules about passwords:

The following requirements apply to passwords:

  1. lVerifiers and CSPs SHALL require passwords to be a minimum of eight characters in length and SHOULD require passwords to be a minimum of 15 characters in length.
  2. Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.
  3. Verifiers and CSPs SHOULD accept all printing ASCII [RFC20] characters and the space character in passwords.
  4. Verifiers and CSPs SHOULD accept Unicode [ISO/ISC 10646] characters in passwords. Each Unicode code point SHALL be counted as a signgle character when evaluating password length.
  5. Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.
  6. Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
  7. Verifiers and CSPs SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant.
  8. Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords.
  9. Verifiers SHALL verify the entire submitted password (i.e., not truncate it).

Hooray.

News article. Slashdot thread.

EDITED TO ADD (10/13): There are potential security issues with allowing arbitrary Unicode in passwords.

Tags: , ,

Posted on September 27, 2024 at 7:01 AM • 42 Comments

Comments

Alan • September 27, 2024 7:18 AM

Those all look good, except #5:

  1. Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.

I think it improves security to force users to pick strong passwords. Requiring a mixture of letters, numbers and punctuation means that the password cannot just be a dictionary word, and therefore I think it improves security.

What are your thoughts, Bruce?

Pascal S. • September 27, 2024 8:40 AM

Excellent news.

I would just extend the 9th rule to not only forbide truncation but also transformation to e.g. upper or lower characters:

Rule 9 : Verifiers SHALL only accept the correct password and not derived passwords (e.g. truncated passwords or passwords that differ by case).

John Faber • September 27, 2024 8:49 AM

Is there a reason for requirement #5: “Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.”

Wouldn’t requiring password complexity enforce a little more security by helping prevent password guessing from shoulder surfing? If making passwords have different types of characters limits the number of potential passwords is a concern, then NIST could address that risk by making requirement #1 for password length longer: “Verifiers and CSPs shall require passwords to be a minimum of twelve characters in length.”

austin • September 27, 2024 10:51 AM

That seems good. I am always mixed about composition rules. Many users have a very hard time with coming up with a password that meets complexity requirements.
Number 9 is really important. I once accidentally discovered my (small) bank was only verifying the first 6 characters of passwords and were normalizing all letters to lowercase… I had a 32 character password from my password manager but accidentally hit backspace twice then enter and it accepted it. I proceeded to test with fewer and fewer then when I got to 6 I added characters after, then eventually typed it without capitals and it still worked. I emailed the bank’s security who replied this was standard regulatory requirement… A month later they emailed me to promote that they changed to verifying 8 characters :-/

Snarki, child of Loki • September 27, 2024 10:57 AM

The “no knowledge-based authentication” is going to run into problems with “I forgot my password/you bastids reset it on me” plus “my old email no longer works”.

Wayne • September 27, 2024 11:37 AM

Seems like reasonable guidelines, though I’m a little puzzled by #5. I’ll read the article and the /. later, and I’m sure Ars will also be discussing it.

I ran into #9 big time with a bank, and closed the account due to it. They changed their online banking system and I had to reset my password. So I did, and it took it. I did my online stuff, signed off, couldn’t sign on again. Called them up for a reset, rinse, repeat, can’t sign on again. This went back and forth a couple more times until the boffin asked how long my password was, and I told them. It was too long. It wasn’t ridiculously long, perhaps 13 or 14 characters, I don’t recall. But if it was too long, why was their entry screen accepting it?

I closed my account soon after.

There was also the little matter of their revealing what their back-end system was during a system crash and their ODBC connector string was revealed: it was Paradox. Not really an industrial-grade database.

Dr Wellington Yueh • September 27, 2024 11:42 AM

“Hooray.”

Agree.

This goes with something I was told a long time ago by my mentor: If you make the procedure for performing a task too difficult, a person will escape procedure to perform the task.

Vincent Archer • September 27, 2024 12:23 PM

People tend to focus on composition rules, but in my experience, they are trivially bypassed by people:
– You uppercase the first letter, so what?
– Replace a by 4, i by 1, e by 3, g by 9, done
– Tack a – somewhere in there, or at the end, done.

One of my friends had a workplace where you were supposed to change your password every month, use the upper-lower-digit-special rule, and not reuse any of your previous passwords. Thank god, it was only 8 characters at the time.

His passwords?

Jan-2018
Feb-2018
Mar-2018
…

Composition rules do nothing to enforce actual complexity.

Virr • September 27, 2024 1:07 PM

#5 No longer serves a good purpose.

The common substitutions most people use are well known.

Unless someone is actually rolling dice to pick random numbers and/or symbols, the picks are rarely random. And reusing the same “random” symbols with a different base password turns out to actually be done, lowering overall security across multiple logins.

Those that actually roll dice to generate diceware passwords that are generally a) long, b) easy to memorize, and c) actually random and secure, often run into problems with “complexity” rules or cause less secure passwords to be used. First the reason to even use a diceware style password is ease of memorization. Adding complexity like random symbols or numbers just makes it harder to memorize, usually means simplifying the password some other way to make it easier to memorize. Examples being adding this “complexity” in a predicable way, using the same symbols/numbers, shortening the password, etc.

For those not using diceware style passwords still can run into problems memorizing extra symbols/numbers and make it more likely they are writing them down.

Typing is generally better on the letters, so adding symbols or numbers slows down typing for most people. Which then lowers ability to develop muscle memory for passwords, introduces way to for timing attacks, slows down typing of passwords, and probably other negative I haven’t thought of. Depending on context of password determines how serious any of these issues are, but it doesn’t help.

#2 is particularly good since I’ve run into password length issues so many times I can’t even count, even without long diceware passwords.

Many of these rules already match current guidelines, or are making those guidelines more explicit, but all of them are good. I’d also bet analysis of data breached passwords across multiple different data breaches probably informed these.

Mopani • September 27, 2024 2:17 PM

Disabling the option to paste a password, or drag and drop (the way Password Safe works) is one of my biggest pet peeves (very close behind only allowing short passwords).

Overall, these “rules” are an improvement, but a complexity metric (like minimum entropy calculation, for example) would be a helpful target instead of simply banning composition rules like “at least one upper, one lower, one numeral, and one non-alphanumeric”.

Required punishment for every admin that enforces arbitrary composition rules: must complete https://neal.fun/password-game/ within 10 minutes.

Clive Robinson • September 27, 2024 3:08 PM

@ Bruce,

Hmm it’s an improvement….

But consider a “human memorable pass phrase” and,

“Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.”

64 characters is way to short.

As I’ve pointed out in the past the first char on average will give you around 4bits, the second 2.5 bits and then on in around 1.4bits of “strength” or less upto around 10 chars then maybe 1bit each or even less.

So humans being humans maybe 17-20 bits of “strength”.

As for,

“Verifiers and CSPs SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant.”

A general “hint” is often designed to be given to an “unauthenticated claimant” as in many systems it’s given prior to login to reduce “help desk” loading.

Also the alternative of “send new pwd to email” has so many failings it to should be disbarred.

Jaime • September 27, 2024 3:25 PM

So many people seem to be surprised that #5 is on the list. This is version four of this publication, and the version three already has password character composition as “Should Not”. Years of experience has shown that people simply don’t make better passwords if you ask them to put in a mix of character types. Most do the obvious minimum transformations that are easily predictable.

On the other hand, composition rules often reject app-generated passwords, annoying those who are making an attempt. Give it up people, making people change their password soften and telling them to make up better passwords is a forty year old strategy that has gotten us to where we are right now.

MK • September 27, 2024 4:25 PM

#4 can be a bit of a problem, because different OS normalize Unicode in different ways. Acrobat allows Unicode, but then does a string normalization (SASLPREP) before testing the password. In hindsight, this did cause problems because of Unicode and PREP changes with time. No real good answers, here.

wallace • September 27, 2024 5:51 PM

The “mixed composition” rules just tend to annoy users, especially because they’re subtly different at every site. And people find ways around them: replace “i” with “1”, append “$X0” unconditionally, etc. It’s extra annoying when the login is not even wanted; like, I hit a login-wall at my local newspaper, agree to make an account, and it’s as if I’m setting up credentials for strategic missile command.

Where the password protects something of importance, it’s probably a good idea for the site to check some dictionaries after “normalizing” the password in various ways (lower-case it, replace “1” with “i”, and so on). Maybe just try to crack it for a few minutes. Of course, the actual password to be hashed shouldn’t be modified (except per standard Unicode algorithms, as noted in the document).

We might also consider just telling the user what the password will be, by default, rather than demanding they come up with one (and then complaining about their first few attempts).

Clive Robinson • September 27, 2024 9:03 PM

Speaking of paying the price of

“Fundemental Password rule breaking”

https://arstechnica.com/security/2024/09/meta-slapped-with-101-million-fine-for-storing-passwords-in-plaintext/

The link kind of says it all Ireland smacks up Meta with a $101million / €91million fine for doing something that has been known to be a stupid thing to do since the 1960’s if not earlier.

At least back in the 1960’s they had a few excuses,

1, Computer communications were normally within a 1000ft range.
2, Active magnetic storage costs were in terms of $X per character.
3, CPU cycles were also very expensive so cryptographic algorithms could make an accountant weep.

P@ssw0rd • September 27, 2024 9:08 PM

@Alan:

Requiring a mixture of letters, numbers and punctuation means that the password cannot just be a dictionary word

No, it forces the use of a dictionary word instead of a random string. Which is more secure, “Runner678!” or “kbndvueepu”?
Password length is the same, but the first has an entropy of ~20 bits, and the second has an entropy of 47 bits. Passwords like “HU:uIj&Y6l” are impractical to memorize and type.
In use cases where the user has to remember a password, requiring a mix of character types actually reduces password complexity by a huge amount. Users have to compensate for the rules by choosing a much simpler password than they would otherwise choose. It’s also true more generally in use cases where the user has to type in a password.

Not really anonymous • September 27, 2024 9:57 PM

So for Unicode there are issues with what an input string means. Are you supposed to use the bits from the encoded code points (typicall utf-8) or are strings which represent the same glyphs expected to be treated as equivalent? If things are compared at the code point level there could be issues with being
able to control the code points used to represent glyphs on different systems. This seems like it has the potential to cause problems for people.

Dave • September 28, 2024 12:29 AM

NIST? The NIST that’s in the US? Setting password rules based on common sense? Are you sure this is from a credible source?

Garabaldi • September 28, 2024 3:48 AM

Hooray.

Particularly for number 5.

https://xkcd.com/936 gives the argument. It is depressing that there are at least 3 people who are taking at least 13 years to understand this.

Have you never learned to type? Have you never had to enter a password with required complexity on a non-keyboard device such as a phone or roku with g*d awful shifting to access non-lowercase characters?

Too bad there is not a “SHALL” in number 2.

J Nimmo • September 28, 2024 5:04 AM

I’m confused that anyone is confused about the rule about composition rules. Obviously, I use a password manager to generate my passwords, with a wide range of characters. But where you cannot use a password manager, and you actually have to remember a useful password, the only practical way to do that is to use a long passphrase.

Adding composition rules into the mix means that one of the following outcomes will occur:
1) You simply capitalize the first word of every passphrase you use, and suffix them with 1234!. Security is not enhanced.
2) You write the passphrase down in full. Security is very much not enhanced.

Winter • September 28, 2024 2:11 PM

Comments along the lines of:

Requiring a mixture of letters, numbers and punctuation means that the password cannot just be a dictionary word, and therefore I think it improves security.

Going from lowercase only to lowercase, uppercase and numbers, you go from 5 bit/character to 6 bit/character. Adding extra character sets adds at most 1 bit per character and character set. Adding 3 characters to a 16 bit password adds as many bits.

For passwords, length Trumps complexity. I once heard of someone who used individual passwords for websites:
I cannot remember very long passwords well + [website name] .

It is not so much that this strategy has high entropy, it’s length is (still) difficult to handle by cracking software.

John Levine • September 28, 2024 2:13 PM

I believe the point of #5 is to let people use password managers and perhaps to let us come up with long passwords we can remember.

There is apparently a theory at some banks that if they have their own strange composition rules, that will force people to pick a password they haven’t used elsewhere. But it usually means they reject strong passwords that password managers invent, so just no.

Robin • September 29, 2024 4:48 AM

Discussion around #5 has concentrated on substituting characters for letters. OTOH I use punctuation. In fact I don’t use words but for example:

“Correct=horSe>batterY+staple!”

Worth it or not?

Clive Robinson • September 29, 2024 6:54 AM

@ Garabaldi, All,

Re : XKCD “horse battery…” Method

You say,

“It is depressing that there are at least 3 people who are taking at least 13 years to understand this.”

And others who still do not get the XKCD’s methods significant failings either.

The incorrect assumption is,

“If I have a word list of a thousand words that is 10bits, so if I randomly select 5 words for a passphrase, I get 50bits of entropy.”

I’ve explained why this is actually not so in the past yet people still ignore it…

So again just some of it’s failings,

Firstly is a technical problem of the assumption that the words are indivisible symbols. They are not,

“Words are not indivisible symbols but strings of characters”

This is important to understand as an attacker is attacking strings of individual characters not symbols.

To see why let us go for a degenerate example, and let’s assume one of your words is “A”. However as a character it’s got less than 4bits of entropy not 10bits as assumed by the XKCD method.

Worse if your random selection pulls out “A A A A A” just how many bits do you think that string has?

If I told you that due to “automobile association” having “AA” and other similar two and three letter acronyms of “AA” or “AAA” used to be first in phone books it brings the entropy down to maybe as little as 9bits in total.

Then there are a couple of human failings to consider,

Humans do not remember random words at all well, so they use “memory tricks”. One of which is to “reorder the sequence” so it “makes sense” as a “phrase”. Another trick is to swap words for other words on the list to do the same thing. Either way the actual entropy falls.

Other things humans do are, “remove duplicate words” and “repeatedly press the button” on the password generator till they get five words they like better. Again either way the actual entropy falls.

The reality is password attacking systems are aware of this and so get the “pass phrase entropy” I gave above not the “five 10bit symbols entropy”.

In reality the XKCD method is probably as bad as a “short memorable pass phrase” entropy wise.

In fact as the chances are high it’s a publicly known word list used in the generator, using words that are,

1, Short
2, Common
3, Easy to spell.

Them it’s probably worse a lot worse in some cases.

Remember when the user types a password or pass phrase in, the length of the password and the typing cadence are in many attack scenarios “known” which works way to easily against a “known word list”.

Who? • September 30, 2024 5:05 AM

[…] Verifiers and CSPs SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant.

I think I do not understand this point… if you are authenticated, why do you need a hint? Ok, I believe what it recommends is that, if you need a hint, you should ask someone that has access to the system right now for it. That is great for small corporate servers, but in this case the administrator can probably help too changing the lost secret, but I can hardly understand how it works for large Internet-based services.

[…] Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords.

My suggestion here, for those systems where KBA is eanbled, is having an answer (the same in all cases) for these security questions. Obviously, that answer must be a good password itself and unrelated to any knowledge. For example, if the security question is “What was the name of your first pet?” the answer should be something like “I32b3d7%#v32d98” (same answer for any security question on any KBA system. Let me say it this way: a recovery password, not a real answer based on our knowledge (and the knowledge of anyone that takes the time to learn about us). The problem here is that answers to these security questions cannot be usually changed over time, so better entirely get rid of these KBA systems.

By the way Bruce… what is your favourite color? 😉

Gert-Jan • September 30, 2024 7:12 AM

…, but a complexity metric (like minimum entropy calculation, for example) would be a helpful target

In the end it’s the entropy that determines the effort (or chance) to crack it with brute force. But the problem is how to determine the range of each character.

If the set “all printing ASCII [RFC20] characters and the space character” is accepted, and let’s assume that’s 95 possible values, then for your calculation, do you assume that an 8 character password has an entropy of some 56 bits? This probably a massive overestimation for the average user password.

Looking at the actual values in the password is hardly an alternative. Because that would mean that the password “011000111000110101011000101010” would be considered to have an entropy of just 30 bits.

Traditionally, the mixed character set composition rules were an attempt to increase the entropy, but with user created passwords, that hardly increases the actual entropy.

MrC • September 30, 2024 9:40 AM

@md:

Further down the section it does say. “Verifiers SHALL allow the use of password managers. Verifiers SHOULD permit claimants to use the ‘paste’ functionality when entering a password to facilitate their use.”

Virr • September 30, 2024 6:49 PM

A password manager can manage more secure passwords than anyone can reasonably memorize. But it is only as strong as the weakest point, which is usually the password securing the keychain. Use a long passphrase or memorize an actual random character password (probably more than 12 characters, but check on what is currently suggested and for how long that is expected to last).

If you need passwords you can memorize better than random characters, and you either cannot use a password manager, or you cannot cut and paste the password (or auto input it), then diceware is probably your best bet.
Diceware style passwords can be secure, BUT there are easy user actions that can make the somewhat less secure to a lot less secure. By design even if the wordlist is known with enough random words picked the search space is too large to reasonably find the password given current computers. All gotchas making diceware less secure, or even insecure, affect this. This is not an exhaustive list.

If not enough words are used then it isn’t secure, current recommendation I think is still 6 or more words. Just like short random characters, 8 or less, is not longer secure against current computers neither are diceware passwords 4 or less words long. Over time computers get better so more words, or random characters, are needed to stay secure.

You actually have to pick words at random, the cheapest way to do this is with physical dice. Programs can be used but might not be trustworthy or using high enough quality entropy. Closing your eyes and “randomly” flipping the page is insufficient. Just role dice to pick words. If you want to be particularly secure buy high quality casino dice.

Diceware needs to have enough characters. If you get too short a password, add a word or discard and start over. A wordlist with good word length makes this unlikely to be an issue.

When you randomly pick words are very unlikely to get duplicates, I’ve never seen it happen so I forget what the best steps are. I’d probably add a word, or discard and start over.

Reordering words lowers entropy, you take the words in the random order you got them.

You do not keep rolling until you get a set of words you like. Again you take the random words in the random order you got, or you can drastically reduce entropy.

Comparing memorizing random works vs words in a sentence with structure, sure the sentence wins. But it is still FAR easier to memorize random words vs a random character password of similar level of entropy. If you find it too hard to remember random words, then pick another solution. Most people find it relatively easy compared to other alternatives of similar security.

Not really anonymous • September 30, 2024 11:47 PM

You probably don’t want to use casino dice for better randomness. If you do, you want to us a large area to roll them and bounce them off a barrier, like you would do in a casino.
Instead most people would be better off buying precision dice (for around $5 a die) which have round corners and will roll better in a small area.

Clive Robinson • October 1, 2024 5:32 AM

@ Gert-Jan, Mopani, ALL,

You observe of “generating” the pass word/phrase,

“In the end it’s the entropy that determines the effort (or chance) to crack it with brute force. But the problem is how to determine the range of each character.”

What is actually the important range is the “attackers” view of the entropy of,

“A string of characters with human memorability”

That is the entropy changes downwards as the layers of human failings are applied.

Humans do not as such remember characters, they learned to spell words. Likewise they do not as such remember words, they remember objects, relations and context words describe, via a set of rules.

It is the limitations of the human ability to remember accurately and that changes a lot not with each human but also what the human is doing.

We can for instance when we hear melody remember the entire words of a song and “sing along”.

But how much do we accurately remember?

If we play the melody as an instrumental, how well do we remember the words?

For most of us we don’t remember the song, we remember the feeling of the story they convey, with individual short phrases acting as prompts to the next phrase and so on. Those phrases act as a form of “Forward Error Correction”(FEC).

So when we “sing along” the words being sung to us tell us the next word or words to sing with the singer with a high degree of accuracy but more distant words in the sentence or verse with less or no accuracy such that whilst we can sing the song we can not just write the words down (try it with something like “The twelve days of Christmas”).

It’s why we remember songs way better than we do poetry, but again we remember a pattern “with meaning” superimposed on the equivalent of rhythm and rhyme so poetry is rememberable to most with a little practice.

There is in effect in the human mind a “moving window” of constrained entropy, that is extended by the equivalent of forward error correction.

Which is why the first letter of a pass phrase has around 4bits of entropy the next couple drop down to just a couple of bits. Then down to less than 1.5bits out to maybe ten letters and from then on less than one bit per letter. And in a lot of cases a dead certainty from then on in all but length and deliberate errors[1].

Which is where the difference in types of pass word/phrase guessing come in.

With modern “smart devices” it’s been demonstrated that any number of “sensors” can act as “usable side channels” to a users actions when typing a pass word/phrase or just even sliding their finger around the screen. The number of keys pressed and the cadence they are typed with are easily picked up not just by a microphone but by watching the energy consumption by the CPU or even shadows on a wall if the conditions are right (same with WiFi acting as “radar”).

But it is more than that, students are adding “Machine Learning” and various claims have been made about the ability to guess the next key entered or position on the screen stopped with between 80 and 98% accuracy.

Ask yourself a question, how long does it take you to know what song is being played?

But what about just words?

That is what entropy is there after,

“The cat sat”…

“We the people”…

“Our father who”…

“Hickory dickory”…

Even Microsoft’s Bing behind DuckDuck “gets them in one” when you search for them. DuckDuck even puts them up in the auto-complete box as you type.

Try typing in the words of your favourite song or poem and see for yourself.

I thought I’d be a little tricksy and try an old song from WWII. DuckDuck nailed it with just “We’ll”.

So think just how easily you could train even a small model LLM to “ring the bell” on passphrases from just word length and typing cadence.

It’s one of the reasons I say,

“Pass words/phrases are dead and should be buried”.

Because due to human failings we can now easily exploit the actual entropy is well below any sensible security margin.

[1] It’s why NIST has it wrong with the not forcing of numbers etc. We have to ensure that “standard phrases” have errors in them as all the entropy little as it is will be in the deliberate errors…

Todd Vierling • October 1, 2024 9:31 AM

(5) Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.

^ This is to address the “Post-It vulnerability.” While the mathematics of https://xkcd.com/936/ can be debated, it makes the point that people cannot memorize multiple compositionally-complex passwords.

This leads to very human vulnerabilities like literally writing them down on Post-It Notes, in notebooks, etc. This has been depicted as an explicit weakness plot point in movies from WarGames (1983) to Ready Player One (2018) and everywhere in between. We culturally know this vulnerability, yet the industry has ignored it for decades. As multiple folks here have mentioned, safe defense against low entropy is length, not complexity.

The weakest link in security is frequently human, not technical, and we have to defend against that too.

(6) Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

^ Nobody here has commented on this, and it’s good we all agree here. This addresses the other major factor in the Post-It vulnerability (difficult memorization).

In the modern era of MFA, a leaked hash is not catastrophic, and there is time to recognize the breach and force a change as noted in the second sentence here.

(7) Verifiers and CSPs SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant.

^ The point of this is not to show password hints to an unauthenticated user on a login page. Password “hints” exist as a supposed solution to the difficulty of memorization, and should be unnecessary with points 5 and 6 implemented.

(8) Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords.

^ This requirement is badly phrased and I’m seeing it misread many places as “KBA banned!” Rather, the way it’s written I interpret as “you cannot demand an answer to a KBA in order to set or change a password.” I don’t know if this is the correct reading.

Robert • October 2, 2024 8:55 AM

@Gert-Jan

The way to gauge the entropy of a particular password is to use the character sets that an attacker would divide the search space into. Specifically the old user favorites of Upper,Lower,Digit,other. A password cracker is going to be looking for passwords built up of pieces containing runs of each of those classes of character. So those regions can be calculated as powers of 10 and 26 for the letters and digits, with a couple of bits for each change. Other is a bit unusual, because it’s likely to be very biased, so I’d probably count them somewhere in 10-16. You’d probably want to slice bits off for matching other patterns too, like titlecase or repetition. Not sure how to add in Unicode, maybe 4000 for the CJK glyphs and 20-30 for the rest?

Your example of “011000111000110101011000101010” would be guessed to about 100bits, while this is an over-estimate IF you KNOW it’s in binary, an attacker isn’t going to have this as part of the normal search order and isn’t going to hit it for a while with numbers.

Gert-Jan • October 3, 2024 7:02 AM

@robert

The way to gauge the entropy of a particular password is to use the character sets that an attacker would divide the search space into

You make a good point. So does Clive.

But if you want to enforce or suggest a minimal entropy, or even if you’d like analytics on the entropy, this doesn’t help a whole lot. I don’t think attackers publish their research or methods or tools (such as dictionaries). And even if they did, you can expect changes / advancements from time to time.

Garabaldi • October 5, 2024 4:54 PM

@Virr

If not enough words are used then it isn’t secure, current recommendation I think is still 6 or more words. … Over time computers get better so more words, or random characters, are needed to stay secure.

Over time the computers used to hash the passwords also get better. The hash algorithms should get longer and more complex so that the cost to verify a password remains roughly constant over time. With a well chosen hash the cost to break the password is a multiple of the cost to verify the password. Thus the length of passwords can remain constant over time and remain secure.

As usual, security practitioners prefer to blame the user instead of updating their hashes.

A two word diceware passphrase can secure $1,000,000 if they use a ten cent hash. A three word diceware passphrase would be enough for most practical purposes for the foreseeable future.

True • October 6, 2024 8:32 AM

@Garabaldi

That is a good point. That also requires the generation of the new hash. So either a new sign-in with the same password that matches the old hash or a forced password reset after the change to a new hash algorithm. Anything about this in the NIST proposal?

Cheshire Sphinx • October 6, 2024 9:08 PM

Warnings have been issued for years regarding computerized voting’s vulnerability to hacking, but the consensus is nothing important has ever happened. Perhaps we don’t need to worry about AI ?

Chris • October 18, 2024 12:34 PM

Rule 2 should say “Verifiers and CSPs SHALL permit a maximum password length of at least 16 characters and SHOULD permit a maximum password length of at least 64 characters.”

Limiting password length to a lower value, eg 8, should be regarded as contributory negligence by the Verifiers if someone sues because their account got cracked.

Robert Thille • October 22, 2024 1:27 PM

There’s a typo in the 4th bullet point.
“Each Unicode code point SHALL be counted as a signgle character when evaluating password length.”

signgle => single.

Leave a comment

Blog moderation policy

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.