NIST Proposes Barring Some of the Most Nonsensical Password Rules (arstechnica.com) 180
Ars Technica's Dan Goodin reports: Last week, NIST released its second public draft of SP 800-63-4, the latest version of its Digital Identity Guidelines. At roughly 35,000 words and filled with jargon and bureaucratic terms, the document is nearly impossible to read all the way through and just as hard to understand fully. It sets both the technical requirements and recommended best practices for determining the validity of methods used to authenticate digital identities online. Organizations that interact with the federal government online are required to be in compliance. A section devoted to passwords injects a large helping of badly needed common sense practices that challenge common policies. An example: The new rules bar the requirement that end users periodically change their passwords. This requirement came into being decades ago when password security was poorly understood, and it was common for people to choose common names, dictionary words, and other secrets that were easily guessed.
Since then, most services require the use of stronger passwords made up of randomly generated characters or phrases. When passwords are chosen properly, the requirement to periodically change them, typically every one to three months, can actually diminish security because the added burden incentivizes weaker passwords that are easier for people to set and remember. Another requirement that often does more harm than good is the required use of certain characters, such as at least one number, one special character, and one upper- and lowercase letter. When passwords are sufficiently long and random, there's no benefit from requiring or restricting the use of certain characters. And again, rules governing composition can actually lead to people choosing weaker passcodes.
The latest NIST guidelines now state that:
- Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords and
- 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. ("Verifiers" is bureaucrat speak for the entity that verifies an account holder's identity by corroborating the holder's authentication credentials. Short for credential service provider, "CSPs" are a trusted entity that assigns or registers authenticators to the account holder.) In previous versions of the guidelines, some of the rules used the words "should not," which means the practice is not recommended as a best practice. "Shall not," by contrast, means the practice must be barred for an organization to be in compliance. Several other common sense practices mentioned in the document include: 1. Verifiers 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 single 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).
Since then, most services require the use of stronger passwords made up of randomly generated characters or phrases. When passwords are chosen properly, the requirement to periodically change them, typically every one to three months, can actually diminish security because the added burden incentivizes weaker passwords that are easier for people to set and remember. Another requirement that often does more harm than good is the required use of certain characters, such as at least one number, one special character, and one upper- and lowercase letter. When passwords are sufficiently long and random, there's no benefit from requiring or restricting the use of certain characters. And again, rules governing composition can actually lead to people choosing weaker passcodes.
The latest NIST guidelines now state that:
- Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords and
- 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. ("Verifiers" is bureaucrat speak for the entity that verifies an account holder's identity by corroborating the holder's authentication credentials. Short for credential service provider, "CSPs" are a trusted entity that assigns or registers authenticators to the account holder.) In previous versions of the guidelines, some of the rules used the words "should not," which means the practice is not recommended as a best practice. "Shall not," by contrast, means the practice must be barred for an organization to be in compliance. Several other common sense practices mentioned in the document include: 1. Verifiers 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 single 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).
This has been recommended for years (Score:5, Interesting)
I used to work at Entrust, a company that a long time ago was an industry leader in public key infrastructure (the are the security in your passport, in the SWIFT banking system and authored many of the early PKI standards), they required changing passwords every 3 months. I did a survey and two thirds of the people admitted their password was a common 6 letter English word with the first letter capitalized and then either '!' followed by a number or a number followed by '!' and that they just incremented the number every 3 months. Most of the others had a common 6 letter word in their mother tongue, two 3 letter English words or used '#'. I suspect most of the few who claimed to have good passwords were lying. I brought this up to management and they didn't care. They just wanted to cover their asses and be able to blame the employees for bad passwords. I've brought it up at another reputable security company and gotten in trouble with HR when I said that these where CYA policies and then had to explain what CYA stood for to the IT security team.
Re:This has been recommended for years (Score:5, Insightful)
People with no real clue _love_ rituals! It gives them the feeling they are doing something right, even when that most definitely is not the case.
Re: (Score:3)
I once did some occasional stuff for a company that took contracts from US regulated companies and so they gave me an account. They had the same password rules. Fortunately they accepted spaces so I could use passphrases. They were all a variation of "this is {PROFANITY} stupid," with {PROFANITY} something creative that amused me to change every three months.
When I ran out of obscene phrases I asked them to disable my account.
Re: (Score:2)
When I ran out of obscene phrases I asked them to disable my account.
Because it was too difficult to use a phrase of some type and simply put some numbers at the end and change those numbers when you had to change your password? I can only imagine the quality of your work if you couldn't do something so simple.
Re: (Score:2)
Why are you such a jerk?
"couldn't do something so simple"... they did do it, and did it in a better way than you recommend.
"simply put some numbers at the end and change those numbers"... changing a word in the phrase adds more security than incrementing a trailing number, you dolt :-)
Such password rules are ill conceived, cause more harm than good, and should be ridiculed. What does that have to do with the quality of their work!?!?!
On a related note, I use random or nonsensical (sometimes offensive) answe
Re:This has been recommended for years (Score:4, Informative)
Re: (Score:3)
Re: (Score:3)
Not only that but you are supposed to be regularly checking the passwords to see if they are in a password dictionary like the one maintained at haveibeenpwned.
correcthorsebatterystaple and 1qaz2wsx are examples of bad passwords. The are bad passwords because they are in password dictionaries, not because of the frequency of any particular characters.
Re: (Score:3)
Can I just use this thread to ask you if my passwords are bad? I'm currently using hunter2
Re: (Score:3)
Can I just use this thread to ask you if my passwords are bad? I'm currently using *******
Sorry, I couldn't see it because it's recognized as a password. See: my password is *******
Re: (Score:2)
This is how the CS college @ Northeastern worked way back when I attended in the 90s. They would periodically run a password cracker over all the shell accounts. If they broke yours, your account would be disabled until you changed the password. Otherwise, the password never expired.
Re: (Score:3)
The tougher the rules, the more likely the password will be on the underside of the keyboard.
Re: (Score:3)
This actually happened once. I was doing a information security inspection at a different unit. The commander was there, and I was giving the classic 'don't write down your password under the keyboard' thing as I turned the closest keyboard over - to reveal a sticky note with the user's password. Totally wasn't expecting that.
I imagine the poor chap got into some trouble.
Bell Labs password rules (Score:2)
Supposedly someone at Bell Labs over 40 years ago came up with a parody set of rules for a strong password. If you applied all of the rules, there was only a single valid password.
Re: (Score:3)
Re: (Score:3)
We should move away from remembered passwords entirely, or at most as part of a 2FA scheme.
We have all the tools. Password managers, security keys, Passkeys.
Re: (Score:3)
We should move away from remembered passwords entirely,
Something you have, something you know, something you are.
Please don't throw away 1/3rd of all possible factors.
2FA and/or MFA are fine. My computer has no biometric ability, so that leaves something I know (password/passphrase/pin) and something I have (computer/securitykey/TOTP secret). Even if my computer had a fingerprint reader or something like that, I have little faith in those being secure. Why are you recommending moving away from remembered passwords ENTIRELY (with an immediate exception following
Re: (Score:2)
Re: (Score:2)
Password1! ends up being the admin password on a lot of test/dev systems.
Re: (Score:2)
Re: This has been recommended for years (Score:2)
I think I got up to "ShittyPassword#27" on the time card system when I worked for a government contractor who forced us to change our passwords every 60 days.
The real PITA was the Linux boxes that would shut off cronjobs for accounts that hadn't had their passwords changed. So that dedicated account that couldn't actually log in (shell was set to /bin/false) and had run fine for over a decade on MacOSX boxes suddenly started failing regularly unless I went in once a month to set another random password for
Yea. Misunderstood. (Score:4, Interesting)
"....The new rules bar the requirement that end users periodically change their passwords. This requirement came into being decades ago when password security was poorly understood...."
Or back when password could be compromised at any point between your keyboard and the server. You could login to a local service or your workstation and leak to a trusted router several hops away.
Re: (Score:2)
"....The new rules bar the requirement that end users periodically change their passwords. This requirement came into being decades ago when password security was poorly understood...."
Or back when password could be compromised at any point between your keyboard and the server. You could login to a local service or your workstation and leak to a trusted router several hops away.
No, that's a different problem, one that wouldn't be mitigated by password change policies. If the password authentication path isn't secure then the game is over, regardless of password quality.
Won't change anything - goes against CYA (Score:4, Interesting)
Re:Won't change anything - goes against CYA (Score:5, Informative)
For one thing I think the SHALL NOT part will force some changes. It's not a recommendation but a requirement.
Also, I'm not convinced people knew this in 1994.
I'm not even certain password salts were the norm back then. How did windows authenticate in NT4, wasn't it still encrypted password over the wire? I kind of remember being able to sniff and brute force over the wire passwords back then, meaning changing you password periodically was pretty relevant into the 2000s.
The fact that we aren't zipping around unsalted hashes to authenticate makes a pretty big difference, and that is a bit the case 30 years ago
Re: (Score:3)
Also, I'm not convinced people knew this in 1994.
Even if people "knew" this, it went against the actual expert advice and guidelines from the NIST - these being what ultimately make the large portion of the cybersecurity industry go round and round. No cybersecurity expert was going to be the one that said "oh no the NIST guidelines are rubbish, just make your password whatever and don't set an expiry" since that would very likely leave them open to actual liability should something have gone wrong. Following standards, even those you may disagree with is
Re: (Score:3)
Everyone should have known this for 30 years but companies want to be able to blame the customers or the employees for any breach. Having a weak passwords makes it easier to pass the blame and Cover Your Ass.
Sorry but no, people should not have known this for 30 years because it explicitly went against the NIST guidelines of the day which formed the basis of how companies handled cybersecurity. The prevailing wisdom was literally the opposite, it even says so right in TFS that password security was poorly understood.
Re:Won't change anything - goes against CYA (Score:5, Funny)
Everyone should have known this for 30 years
We know this since August 10, 2011 [xkcd.com].
NIST is right and wrong (Score:2)
Random character passwords are no more secure against brute force or dictionary attacks than short phrases... but they are too difficult for humans to remember so they are more likely to end up on post-it notes.
Changing passwords limits the duration during which a compromised password can be used, but any password age greater than an hour is pointlessly long compared to a scripted attack. It is better to invest in detecting abnormal activity and locking accounts than it is to force a password change on a p
Re: (Score:2)
If you follow NIST guidance that passwords should be at least 15 characters in length, then password complexity rules no longer matter. That length of password is long enough to thwart dictionary attacks, even if everything is all lower case.
Re: NIST is right and wrong (Score:5, Insightful)
Re: (Score:2)
Absolutely right. But nobody is going to make companies follow these rules, they're going to do whatever they please regardless of NIST advice. I've been using NIST guidance to back up my resistance to some of these dumb rules for years, and so far, pretty much nobody listens. They're married to these fancy rules that nobody can remember, like "One upper and lower case letter, and one symbol" and so on. It's as if it's some magic incantation.
Re: (Score:2)
But nobody is going to make companies follow these rules, they're going to do whatever they please regardless of NIST advice.
1. Companies must comply if they do business with the government, which is a lot of companies.
2. If companies fail to follow standard "best practices", they are vulnerable to a big lawsuit if there is a breach.
Re: (Score:2)
Companies must comply if they do business with the government, which is a lot of companies.
This is only true if the specific government agency includes a reference to the NIST guidance in its regulations. There are a whole lot of government agencies, especially smaller regional ones like school districts, that do not have such sophisticated understanding of technical requirements.
Re: (Score:2)
70^15 is a much bigger number than 26^15.
If the latter were standard, rainbow tables would become practical for longer passwords.
Re: (Score:2)
70^15 is a much bigger number than 26^15
Yes, this is true, but for purposes of security, is not significant. 26^15 is 1,677,259,342,285,725,925,376. That's a whole lot of combinations, enough to thwart any kind of brute force attack. Even with your rainbow tables, if the attack was able to try a trillion combinations per second, it would take 53 years to try them all. If an attacker has that kind of resources, they'll just find a back door (you know, like phishing) to get around the password, because at that point the password is no longer the we
Re: (Score:2)
You double the size of the required table by using mixed case
It's much more than that.
For 8-characters PWs, the table is 256 times larger.
For 16-character PWs, it is 65536 times larger.
Re: (Score:2)
> However, requiring mixed case and special characters? If you give that up you drastically reduce the difficulty of dictionary attacks. You double the size of the required table by using mixed case, triple it with special characters.
Using a random collection of words, the first one capitalized and ending in a couple of special characters would seem to meet the requirements, and still be easy enough to remember that one wouldn't be tempted to put it on a sticky note.
Re: (Score:2)
Locking to specific IPs is increasingly worthless due to widespread NAT, you will end up allowing an entire ISP or telco.
Locking accounts just because some failed attempts were made allows for a trivial DoS that the users can't do anything to prevent, abnormal activity should be users who have successfully logged in (ie an actual account compromise).
Forcing 90 day password changes in most cases does very little to prevent anything, most users have passwords which are trivially easy to guess if you know the
Re: (Score:2)
Locking to specific IPs is increasingly worthless due to widespread NAT, you will end up allowing an entire ISP or telco.
Furthermore, the apparent source IP can easily change many times during even a short session. I see this all the time with users that are funneled through a proxy that has a pool of outbound IP addresses. It pains me that we can't lock a session to a source address, as that made stealing a session much more difficult (even if it was still feasible).
Re: (Score:2)
However, requiring mixed case and special characters? If you give that up you drastically reduce the difficulty of dictionary attacks. You double the size of the required table by using mixed case, triple it with special characters.
Exactly. I always mix cases and special characters. If it is that hard for people to remember them, they need to use Prevagen.
I use my dog's name (Score:5, Funny)
My dog is named %8Nk=14hD
Re: (Score:2)
Oh no! Now I'm going to have to change the password on my luggage!
Re: (Score:3)
What? It's related to my cat, &yHea=14hD?? Same last name!
Re: (Score:2)
I did that once, and then one day my bank was all "today instead of logging in with your password, you need to put in your pet's name". That took a long time to resolve, now I also save the answers to the incompetence questions (all gibberish of course, glad NIST agrees with me).
Re: (Score:2)
Nice to see there are multiple others doing this as well. I'll be screwed if I lose my password vault, but no one is using my security questions to get my account!
Re: (Score:3)
my security questions
There is a customer of a bank that allowed users to specify their security question plus the correct answer. She entered:
Q: You're not going out dressed like that, are you?
A: I don't have to listen to you. You're not my real father anyway.
Re: (Score:2)
Why don't you name your dog something simpler like fluffy so you can have an easier password?
Re: (Score:3)
My dog is named %8Nk=14hD
Found Elon Musk.
Good recommendations (Score:2)
I like the new recommendations except for one. The recommendation that passwords MUST be at least 8 characters long and SHOULD be 15 is not strict enough. I think the MUST should be 10 or even 12.
I think we should force people to use longer passwords to encourage them to use password keepers. Password keepers make it easy to use long, random passwords and to use different passwords on different web sites. Of course, the password keeper itself should be protected with a long passphrase and 2FA.
Re: Good recommendations (Score:2)
Re: (Score:2)
Yes, sure, so those old systems exist, but the standards could apply to all new systems.
Re: (Score:3)
Then fine, make the rules apply everywhere and declare the old systems non-compliant.
The alternative is essentially to allow downgrade attacks until the end of time.
Password (Score:5, Funny)
Change your password every week to a bunch of random alphanumeric and special characters. How is that difficult? It's called password hygiene. And don't give me any BS about what happens if you forget, just put the password in a text file that you can access on the web. Make sure it's secured with https.
Re: (Score:2)
"Change your password every week to a bunch of random alphanumeric and special characters. "
Good advice for anyone from New Jersey wanting to be Mayor of New York.
The best password is (Score:4, Insightful)
Control-V
Re: (Score:3)
Local password managers really should be more of a thing.
Passwords are overrated (Score:2)
If you need real security, add a 2nd factor. You cannot make passwords secure, regardless of rules. Stop trying.
Re: Passwords are overrated (Score:3)
Re: Passwords are overrated (Score:2)
Re: (Score:2)
1 - If MFA is locking you out, you're doing MFA wrong.
2 - Agreed token theft is a genuine issue but only because the token recipient goes out of their way to engage with phishing mails.
3 - Before complaining about password rotation, you may want to do research on how large the cyber threat markets are. There is serious funding there and it is growing by leaps and bounds every year.
4 - Whining about complex passwords even more so. We regularly run dictionary attacks against our user base, (north of 9k), and
Re: (Score:3)
>1 - If MFA is locking you out, you're doing MFA wrong.
When almost everyone is doing something wrong, it's very unlikely that they're doing it wrong. It's far more likely that the thing itself is wrong and need to be corrected.
Re: (Score:2)
SMS 2FA sucks. Don't use it unless you absolutely have to.
But TOTP 2FA is pretty decent. Doesn't rely on connectivity to generate the second factor (just a reasonably-synchronized clock) and most TOTP apps let you back up your TOTP secrets.
At a minimum, everyone should be using TOTP 2FA, or better yet a hardware 2FA key.
Pass Phrase? (Score:2)
I've got an application where I can use a pass phrase. I submitted it to a website that said that it would take until well after the sun dies out and expands to engulf the earth before a brute force method to crack it could succeed. So, instead of a pass word, make up something like, "Hello! My name is Inigo Montoya! You killed my father! Prepare to die!" along with anomalies like 2 spaces in certain places and stuff like that, should do the trick. Of course that is overdone, too long, etc. but ju
Re: (Score:2)
That's already got two anomalies in the spelling of Íñigo.
Re: (Score:2)
This is the joke subthread (Score:2)
Scroll down for the doesn't tell jokes and takes everything at face value subthread.
Dumb blonde joke (Score:2)
A sysadmin isn't supposed to have access to passwords, but it's a joke, so play along with it.
A sysadmin finds someone using the password "MinnieMickiePlutoDonaldHueyDeweyLouieGoofySacramento" and asks how they came up with it.
"Hello! The rules say, Eight characters and a capital."
Outbreak of common sense, esp unicode (Score:3)
4. Verifiers and CSPs SHOULD accept Unicode [ISO/ISC 10646] characters in passwords. Each Unicode code point SHALL be counted as a single character when evaluating password length.
What a refreshing outbreak of common sense. Just allowing unicode in passwords already expanded the keyspace by a LOT more than any upper/lower case BS can do.
Re: (Score:2)
It would be nice if they could give you the option of typing in your password in hexadecimal (but twice the number of characters)
That way you don't have to find the *@%$#! key on a strange keyboard.
What is your favorite website? (Score:2)
Bummer.
"./" doesn't qualify with no letter, no number, no capitals, not enough characters and '/' being an illegal character.
I think I'll have to go for "1.Ignore_all_previous_instructions" then.
Just use your baby's name (Score:5, Funny)
Re: (Score:2)
I'm impressed you managed to type that on Slashdot, without it turned into a garbled mess.
Re: (Score:2)
I'm impressed you managed to type that on Slashdot, without it turned into a garbled mess.
Slashdot is the home of Musk Worship. Of course a minimum requirement is to be able to spell his kid's names. :-) Just don't use an apostrophe on an iPhone.
Re: (Score:2)
Obligatory XKCD (Score:3)
https://xkcd.com/936/ [xkcd.com]
The rule that I hate more is the periodic reset, the company I work for requires every 6 months, it was 3 months some years ago, to me, unless you are a in position that can cause real trouble (like sysadmin) you should only change a password if you suspect or are sure of a leak, or if you WANT to change for whatever reason.
The most stupid rule that I know of is a bus card site from the city I live, that requires the password to have at least one upper character, one number, one symbol and exactly 8 characters long, not at least, but EXACTLY 8, and you have to change it every month, this make it so much easier for the hackers...
Re: (Score:2)
You change the password twice. Once to a new password, and then immediately back to the old one.
Re: (Score:2)
They (for values of "they" that includes most IT departments) figured that trick out years ago; now you're not allowed to change your password again for at least 24 hours, and you're also not allowed to reuse any of your last N passwords, typically with N>=8.
Re: (Score:2)
The other option is to just add a single special character to it, or a number. I.e. "mypassword" becomes "mypassword1" or "mypassword!" and so on.
Praise jesus for #8 (Score:3)
Re: (Score:2)
No kidding on the "secret" questions. I remember that several politicians, actors, and athletes were compromised not because somebody guessed their password, but because they were able to get through the "secret" questions and reset the password and download all the emails/information before the user, figuring something weird happened, reset the password again. Maybe they realized what happened, maybe they didn't.
Re: (Score:3)
Agreed 100%. Many of the "security" questions could be answered by immediate family or Facebook friends. Poorly written questions are ambiguous, leading to mistakes by the correct user. (And don't get me started on case and whitespace sensitivity!)
Not all bad actors are l33t haxxors. Toxic friends and family can do just as much damage if they can reset passwords.
My answers are a random word, stored in the "notes" section of my password manager.
Knowledge based (Score:2)
So no more requiring users to include the solution for a chess puzzle in their password., nor requiring users to know the location of Google Street View. I'm sure one can live without that.
Oh, that knowledge. That would be slightly harder to shake off, as that's basically the easiest way to get around a forgotten password, and there's still no easy method that keeps u
Re: (Score:2)
Oh, that knowledge. That would be slightly harder to shake off, as that's basically the easiest way to get around a forgotten password, and there's still no easy method that keeps unauthorized users out (especially with social engineering tricks, etc.)
A lot of the time I have problems with this, because I don't want the obvious stuff, which other people could guess. "Favorite" movie/song/actor whatever changes depending on my mood - it's unlikely to be the same in six months.
I usually just set them to another password. Was a bit awkward when it turned out that it was used in authentication during customer support calls. "What's your pet's name?" I could literally hear her brain segfaulting when she saw what was in the field. A 15 character list incl
Re: (Score:2)
Oh, and those recovery questions are one of the main ways that politician/famous people accounts get compromised and "juicy" details stolen.
This is all moot (Score:3)
I can make my password tough to guess or break, but my bank will still insist on using an easily acquirable piece of information for password recovery. My password is 0837H(*&^@##)(%*dsl$kx%n&sc but the recovery password can be ascertained with an online public records lookup. (Mother's maiden name, father's middle name, etc.)
I know, your work wouldn't do that, and neither would mine. But financial institutions still do. I'm told it's to reduce load on the help line.
Re: (Score:2)
I lie, on the assumption that they won't do a public records lookup. The trick is to remember what lie you told them.
Re: (Score:2)
I lie, on the assumption that they won't do a public records lookup. The trick is to remember what lie you told them.
Yep. One strategy is to use the same lie everywhere, have a set of incorrect answers to common security questions that you use. That makes it easy to remember... but means that an attacker who compromises the security questions database at one site has your answer for others.
Really, the only answer is to treat security questions like additional passwords. Pick high-entropy random values for your answers, and store questions and answers securely, in something like a good password manager.
Mxyzptlk (Score:2)
Something tells me that this is not a secure password.
Sigh. (Score:3)
25 years I've been telling people all of this (alright, not the Unicode stuff, but I get that), and still *Apple* accounts are one of the worse offenders.
Entropy calculation (Score:2)
IMO the main issue with these kinds of passwords rules is that they cannot be spelled out in simple terms, such as minimum length, character type, etc. They need to be expressed in terms of password entropy. If I have a very short password that uses a very large variety of character types (that is punctuation, upper and lower case, numbers and letters) then it may have enough password entropy to be secure. Or conversely I can use a long password (12-16 chars or more) that is purely lower-case and achieve th
Always Assuming that Brute Force is the Problem (Score:2)
Does not disagree with PCI DSS 4.0 (Score:2)
I have seen some people saying that they can't follow these new NIST guidelines because PCI DSS has not caught up. That's not true.
The PCI DSS 4.0 self-assessment questionnaire [pcisecuritystandards.org] section 8.3.9 says, in summary, that you don't need to change a password regularly if it uses EITHER multi-factor authentication OR has a dynamic zero-trust security assessment ("The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.")
Only if you are not us
Re: Since when does... (Score:2, Offtopic)
My cat get 12 rods to the hogshead and that's the way I likes it!
Meow.
Re: Since when does... (Score:4, Insightful)
My cat get 12 rods to the hogshead and that's the way I likes it!
Now, THAT is a good password, right there.
Re: (Score:2)
Re: Since when does... (Score:5, Insightful)
Which is why the number one important change, the one that requires them to display the password rules by the password entry box so you donâ(TM)t guess every password you reuse exposing all of them, is not included here.
Re: (Score:3)
Since when does NIST bar nonsensical anything? The nonsensical, ineffective, and standards which openly subvert their stated purpose are sort of NIST's bread and butter.
Your characterization is completely at odds with my (deep, extensive) experience with NIST standards, at least in the area of security. Their standards are almost always extremely well thought-out, thoroughly documented and provide very good security advice. The only clear exception I can think of in the last 30 years is Dual_EC_DRBG, which I'm sure was forced on them by the NSA, and I'm sure many people in both agencies thought it was a foolish idea, doomed to discovery. I'm also a little unhappy with the
Re: (Score:2)
Beat me to it by 9 minutes, but I wholeheartedly agree with a few of the recommendations, namely not having to change passwords. I would have put the minimum password length at 15 like they said organizations should, because 8 is just too short. And I would not have recommended the unicode bit. The knowledge-based passwords hints are a disgrace to online authentication. So many organizations use the same questions and you don't even know if they same checksums or answers to the questions.
Re: (Score:2)
This is exactly what I have being doing for years; long passphrase easy to remember but more cumbersome to type without visual feedback. I simply incorporate one or two non existing word one being like YY77!! so password strength test pass on most sites. With non-existent words are incorporated, it make the passphrase really hard to crack with dictionary based attacks.