Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Privacy

NIST Proposes Barring Some of the Most Nonsensical Password Rules (arstechnica.com) 125

Posted by BeauHD from the password-hygiene dept.
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).

NIST Proposes Barring Some of the Most Nonsensical Password Rules More | Reply

NIST Proposes Barring Some of the Most Nonsensical Password Rules

Comments Filter:

  • This has been recommended for years (Score:5, Interesting)

    by FeelGood314 ( 2516288 ) on Thursday September 26, 2024 @09:40PM (#64820529)
    The last NIST publication on shared secrets (passwords), explicitly spelled out that it was a bad idea to have mixed case, symbols and numbers. Every security specialist worth minimum wage has known for 30 years not to require passwords that are hard to remember and only in the case of compromise to force password changes.

    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:4, Insightful)

      by gweihir ( 88907 ) on Thursday September 26, 2024 @10:39PM (#64820615)

      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)

      by ceoyoyo ( 59147 )

      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.

      • 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)

          by unrtst ( 777550 )

          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)

      by JDShewey ( 1060926 ) on Thursday September 26, 2024 @11:53PM (#64820729)
      I suppose you will be shocked to hear, then that Entrust just lost their webtrust and their certificates are no longer going to be trusted by browsers any longer...
      • Why would the parent be shocked? Entrust has definitely fallen from grace. But, at one point, the company had a good reputation. The OP no longer works there. They even said that "a long time ago [Entrust] was an industry leader in public key infrastructure." Clearly, at some point, the company tried to cut corners in the name of increased profits and is now paying a penalty. That doesn't diminish that, at one point, they had really good people doing really good things. And the post itself is informa

    • Re: (Score:3)

      by micheas ( 231635 )

      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.

      • Can I just use this thread to ask you if my passwords are bad? I'm currently using hunter2

        • Re: (Score:2)

          by unrtst ( 777550 )

          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)

        by flink ( 18449 )

        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.

    • The tougher the rules, the more likely the password will be on the underside of the keyboard.

      • 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.

      • 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)

      by AmiMoJo ( 196126 )

      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:2)

        by unrtst ( 777550 )

        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)

      by Sique ( 173459 )
      I always thought it funny that Asd123!. is a valid password under most password rules.
    • Short version: This article is about Revision 4. Revision 3, which had pretty much all of the same recommendations, was published in 2017.

    • 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)

    by dowhileor ( 7796472 ) on Thursday September 26, 2024 @09:41PM (#64820533)

    "....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.

    • "....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)

    by FeelGood314 ( 2516288 ) on Thursday September 26, 2024 @09:42PM (#64820535)
    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.

    • Re:Won't change anything - goes against CYA (Score:4, Informative)

      by AvitarX ( 172628 ) <me@b r a n dywinehundred.org> on Thursday September 26, 2024 @11:31PM (#64820701) Journal

      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

    • 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.

  • 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

    • 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)

        by Speare ( 84249 ) on Thursday September 26, 2024 @11:13PM (#64820681) Homepage Journal
        I was surprised they still think the acceptable character set "should" include all of printable ASCII instead of demanding it. So many systems which can't take semicolons, quotes or percents, because they still have database injection concerns they should have fixed twenty years ago.

        • 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.

          • 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.

            • 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.

      • 70^15 is a much bigger number than 26^15.

        If the latter were standard, rainbow tables would become practical for longer passwords.

        • 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

    • 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.

    • > 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)

      by Bert64 ( 520050 )

      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)

        by unrtst ( 777550 )

        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).

    • 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)

    by PPH ( 736903 ) on Thursday September 26, 2024 @10:04PM (#64820567)

    My dog is named %8Nk=14hD

    • Oh no! Now I'm going to have to change the password on my luggage!

    • Re: (Score:3)

      by dskoll ( 99328 )

      What? It's related to my cat, &yHea=14hD?? Same last name!

    • 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)

        by unrtst ( 777550 )

        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!

    • Why don't you name your dog something simpler like fluffy so you can have an easier password?

    • My dog is named %8Nk=14hD

      Found Elon Musk.

  • 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.

    • Unfortunately there are still old systems out there that cap out at 8. I used to do work for a utility and they had a system for syncing passwords between internal systems when you reset on. Passwords had to be exactly 8 characters. No more, no less. And only a couple of special characters were allowed. This was due to an old system in the mix that ran half of the entire place. I suspect the US gov has plenty of antiquated systems that is preventing NIST from making something over 8 characters a must.

  • Password (Score:5, Funny)

    by backslashdot ( 95548 ) on Thursday September 26, 2024 @10:23PM (#64820595)

    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.

    • "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)

    by rossdee ( 243626 ) on Thursday September 26, 2024 @10:42PM (#64820627)

    Control-V

  • If you need real security, add a 2nd factor. You cannot make passwords secure, regardless of rules. Stop trying.

    • Like SMS on your phone that just got sim swapped?

  • 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)

      by pjt33 ( 739471 )

      That's already got two anomalies in the spelling of Íñigo.

    • The 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" has now added your pass phrase to it's dictionary and your pass phrase is now compromised. Congratulations, you fell for a phishing attack.

    • 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)

    by khchung ( 462899 ) on Thursday September 26, 2024 @11:02PM (#64820663) Journal

    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)

      by rossdee ( 243626 )

      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.

  • 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)

    by Gavino ( 560149 ) on Friday September 27, 2024 @01:11AM (#64820825)
    If your baby is named "X Æ A-Xii"

    • Re: (Score:2)

      by AmiMoJo ( 196126 )

      I'm impressed you managed to type that on Slashdot, without it turned into a garbled mess.

      • 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)

        by McWilde ( 643703 )
        How is this not a garbled mess?!

  • Obligatory XKCD (Score:3)

    by esperto ( 3521901 ) on Friday September 27, 2024 @01:13AM (#64820833)

    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)

      by Luckyo ( 1726890 )

      You change the password twice. Once to a new password, and then immediately back to the old one.

      • Re: (Score:2)

        by Entrope ( 68843 )

        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)

          by Luckyo ( 1726890 )

          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)

    by paul_engr ( 6280294 ) on Friday September 27, 2024 @01:36AM (#64820855)
    The "secret" questions are the dumbest fucking garbage ass bullshit ever. Fuck you, microsoft. Also, fuck pins being "more secure"

    • 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.

    • 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.

    • Re: (Score:2)

      by sconeu ( 64226 )

      The trick is to make up bogus answers to the "security" questions. Of course, then you need to REMEMBER those bogus answers.

  • 8. Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA)

    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.

    (e.g., "What was the name of your first pet?")

    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

    • 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

    • 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)

    by roc97007 ( 608802 ) on Friday September 27, 2024 @03:04AM (#64820913) Journal

    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)

      by pjt33 ( 739471 )

      I lie, on the assumption that they won't do a public records lookup. The trick is to remember what lie you told them.

      • 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.

    • Something tells me that this is not a secure password.

  • Sigh. (Score:3)

    by ledow ( 319597 ) on Friday September 27, 2024 @04:03AM (#64820961) Homepage

    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.

  • 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

  • I think that there are too many people clicking on the monkey, and not paying attention.

  • 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

  • Can the new standard be extended to include the corporate death penalty for site operators that in the setup screens for a new user account accept a generated strong password without giving your browser the prompt to save that password. Now you don't have access to the account you just set up.

Slashdot Top Deals

1 Sagan = Billions & Billions

Close