NIST doesn't "Advise Against Periodically Changing Passwords". There is no issue with periodically changing passwords in and of itself.
NIST is acknowledging that the typical user when faced with a password policy that requires a regular password change will choose a weaker password. NIST is advising against imposing a requirement to periodically reset passwords.
Maybe I'm nitpicking but the title as it currently stands is misleading in my opinion.
> There is no issue with periodically changing passwords in and of itself.
I suppose this is true as long as you're not having to record the password in some insecure place (like a sticky note on your monitor) because you can't remember it. In practice, this seems to require either (a) using a password manager or (b) keeping most of the password the same and just changing one or two characters (because learning a completely new random password every 90 days is too hard).
In case (a), periodically changing the password is not harmful, but it's also completely pointless; just have your password manager generate a 16-character or longer password, and there's no need to change it, unless you're aware it's been compromised.
In case (b), again, periodically changing it is not harmful, but it's also probably pointless. Consider that if an attacker learns your password somehow, and you don't know about it, they're likely to have weeks if not months of unfettered access. Then one day they try to log in as you and can't; seems like the first thing they're likely to do is to try small variations on the password they've been using, whereby they're likely to find your new password.
Anyway, I've never heard of a user imposing a password rotation policy on themselves. Have you?
Not password rotation per se, but i do have a tiered set of passwords, and every now and then change up the most secure password to something new and demote the rest.
I disagree. In principle, every time a password is changed is a point of failure - it's additional overhead that has the opportunity to go wrong. If a password does not need to be changed, don't change it. Set it and forget it.
If you generate strong passwords, store them securely in a password manager and use different passwords for each account, you shouldn't need to force a password change unless the password is compromised or technology evolves to make it insecure.
I agree the title that it's bad as well. It eventually creates password fatigue and users are less likely to expend mental effort picking good passwords if they know those passwords are going to be thrown away in 90 days.
Really the only thing I recommend anymore is a good password managers. Use one very strong password, perhaps changed every 2-3 years if you feel the need, to unlock one or more secure private keys with which all your passwords have been encrypted.
The great thing about good password managers that use asymmetric cryptography is that my password is not really the weakest link. If you have access to my hardware, then guessing my password will potentially help you, but otherwise you'll have to break my pgp key (assuming you can also get access to the encrypted password store).
At that point I don't really care what your rotation policy is. I can generate a new password every 90 days with no real fatigue.
We will just have to disagree. With time, all passwords can be brute forced. If you change them periodically, using a pw manager and/or a strong methodology, then it becomes more expensive to keep brute forcing.
History shows us that sites are popped on a regular basis and their users do not always find out right away. Sometimes the org in question doesn't even know for a while.
> With time, all passwords can be brute forced. If you change them periodically, using a pw manager and/or a strong methodology, then it becomes more expensive to keep brute forcing.
That doesn't make sense. If a password already takes longer than the age of the universe to practically brute-force, you're not meaningfully gaining anything by forcing users to change their passwords periodically. On the other hand, you are introducing more opportunities for mistakes to occur in what is already the most dangerous failure point (the human).
I left in a reasonable acknowledgement that technology changes can make currently safe passwords weak in the future. That's a good reason to change a password. But periodic password changes don't make sense unless "periodic" refers to timescales longer than anyone here has been alive, because it's inconsequential compared to the cover time provided by a strong password.
The argument that passwords should be rotated is mostly a response to users predominantly choosing weak passwords. But if you're in a position to enforce password rotation, you're also in a position to enforce strong passwords. Password rotation is a usability-reducing, incomplete and poor method of enforcing user safety. It is wholly superseded by encouraging people to use password managers, which is a much more optimal and complete solution that does not fatigue the user. Password managers make rotation obsolete, can incorporate password breach monitoring and be made virtually frictionless (they can be incorporated directly in the browser and turned on by default).
> store them securely in a password manager and use different passwords for each account​
You are about the 2% of the tech crowd (i.e, bay area software/data people). The vast majority of engineers do not use a password manager, let alone the entire US populace.
You severely overestimate the amount the average person cares about password security.
We're talking about best practices; I didn't make any claim about how many people use password managers.
The point remains - if you want to follow password best practices and optimize for user safety, don't enforce arbitrary password changes. You're right about ordinary users - we should provide them with fewer opportunities to shoot themselves in the foot. The lower the frequency they have to focus on generating passwords, the better.
True. But its not just the Bay Area. My wife uses LastPass and 2FA and tells others about it at work and she's a mental health counselor, not a software engineer. I guess my influence did have some influence. My parents are also on 2FA. We're in the Atlanta, Georgia, area, not the Bay Area ;-p
id much rather have a reasonable solution for widespread 2 factor authentication than this password mess.
with my bank i have a password, an app on my phone that generates a key and if i perform significant transactions, they call me to confirm before processing it.
the idea that i'm going to use a different password for every stupid site out there that i have an account with is a bit silly. if someone desperately wants to compromise some of them then so be it. hijack my twitter if it makes you feel better. im not going to waste mental energy on securing social media.
"just use a password manager" sounds cute. password managers are compromised, too. password managers are about as trustworthy as the people who operate them. theres no way im handing my passwords for bank accounts over to some random company and for passwords that protect pointless internet nonsense, im not going to use one either because its irrelevant.
you can invoke this whole "password managers are secure" hoohaa. if they ACTUALLY encrypt your passwords properly and ACTUALLY dont save them on their own servers for whatever they want to do with them later, then yes, they probably are secure. but theres no way to be sure that thats the case. Trusting a password manager introduces more uncertainty into your password woes than they will ever make you more secure, if you really think this whole thing through.
the other issue with a password manager is that in theory, they work across platforms. that ends rather abruptly when youre not in a browser and need to enter a password into an app on your phone.
You seem to be operating under the assumption that all password managers are netbased and commercially operated.
This is not the case for PasswordSafe, not the case for the various Keepass implementations out there, and not the case for several other, lesser known projects.
I am a happy, contended and reasonably safe KeepassX user since many years ago. While I do see the point of two factor auth in certain situations, I sincerely hop and pray it never takes off in a mandatory big way, uncalled for annoyance as it is in most cases. My 36 character passwords usually do the job just fine.
> if someone desperately wants to compromise some of them then so be it. hijack my twitter if it makes you feel better. im not going to waste mental energy on securing social media.
This is a bit short sited; if you use the same password for everything and your Twitter account gets broken into, then every site where you have the same email address is potentially also broken into
You don't need to use a web-based password manager.
I use the standalone KeePass app across all my devices, and can paste passwords into apps with no browser access required. I believe KeePass is widely regarded by those who know more than me as cryptographically solid. The only pain point is keeping the databases synchronized across all devices, but it's not that difficult.
That ... seems like an issue with periodically changing passwords.
You can't take the human factor out of the equation here, no matter how much you might want to. Passwords exist because of the human factor, otherwise we'd just use 4096-bit keys or something.
"The National Institute of Standards and Technology (NIST) is no longer recommending people periodically change their passwords as part of the organization’s new draft of its Digital Identity Guidelines."
Untrue, misleading, and possibly harmful.
NIST isn't recommending USERS stop changing their passwords. That would be insane. They are recommending that services stop enforcing periodic password changes on users because it ends up hurting the user in the long run. (Ie, passwords should be easy for users and hard for attackers).
I think the keyword is "periodically". They're not saying not to change passwords for any reason; they're just saying not to do it solely because the password has been in use for some fixed amount of time. That recommendation applies to users as well as to services setting password policy.
NIST have an interesting history around security. One such example would be AES. They favored Rijndael over Serpent, despite Serpent clearly winning on technical merit. Also, Rijndael is the one cipher that intel have offloaded on their chips and even called it AES-NI vs. offloading several ciphers.
I agree with some comments here that size matters. It is trivial to put a series of characters in between 2 to {n} words you can easily remember.
____This____Is____Number____42!____ and I would remember it is 4 _'s around each word because there are 4 words/numbers.
More sensitive content should equate to more words; and therefore, more of the buffer characters.
You can even use this to defeat keyloggers. Open up a prompt that you can type in, then type a bunch of a character. Then use your mouse to select the number of characters that represents your buffer character length, or a portion of it. Then copy-paste as required. Keyloggers will capture cntr-v but they won't capture how many characters you selected.
For those concerned about password managers and keyloggers, don't put your actual password in them. Leave off something, somewhere in your password. Maybe the start of your pw actually contains buffer characters that you know to type or paste.
A majority of folks won't be bothered to do any of this. I am just sayin', it's super easy once you train yourself.
First and most importantly, you have the chronology backwards --- obviously, Intel implemented AES-NI after NIST chose AES. If NIST had chosen Serpent, AES-NI would implement Serpent. That's the point of encryption standards.
Second, Serpent had a higher security margin, but was slower, and more complicated; among other issues, Serpent has a higher hardware footprint. None of the AES finalists have been meaningfully weakened since AES was selected.
There are obviously sketchy NIST crypto standards, and at least one very bad one. AES isn't either of those kinds of things.
> First and most importantly, you have the chronology backwards
No, you and I are saying the same thing. Perhaps I worded it poorly? My point is they are fixating on a specific cipher they believe everyone should and will use. As it turns out, most are because Intel backed their choice and gave people incentive to utilize it.
If fixating on a specific cipher is considered to be a standard, then let's deprecate it. I believe that was done in error. The standard should be around how each cipher is implemented in a secure manor, not limiting options to one cipher.
By diversifying options, brute force attempts get exponentially more expensive. It would be easy enough to list in CPU capabilities which instructions are supported.
I think what LinuxBender may be trying to say is that if everyone standardizes down to a single cipher, that's not a good thing when that one cipher is shown to be a poor choice. It might be nicer if people have a few choices, so we have freedom to disable some of them when one becomes a poor choice.
Ex: when TLS clients and servers commonly supported 3DES, RC4, and AES, it wasn't universally painful to disable 3DES and RC4 (although if you support(ed) embedded clients without AES support, it's still painful). I think ChaCha looks to be a second good option that's gaining support.
Algorithm agility was once considered best practice and all but mandatory.
20+ years of issues with SSL and SSH, both in the standards and implementations, has taught us that the costs of supporting algorithm agility is much more than the gains. Borderline intolerable, in fact. Moreover, our two-decade track record of cryptanalysis and predictions of future breakthroughs has been very good.
We're much better able to predict the costs+benefits of a particular cryptographic primitive than we are of the protocols and software we build. If a cryptographic primitive is assessed as good enough, it's no longer considered desirable or even reasonable to hedge that assessment and permit substitution of the primitive during the lifetime of the protocol. The resultant complexity is much more likely to be the source of future problems than the primitive.
I like ChaCha. I like AES. Systems should choose one or the other. Part of the point of ChaCha is to exploit the capabilities of general-purpose processors to get fast encryption without special-purpose hardware acceleration.
What people should not do is cascade ciphers, or, even worse, build systems that allow for cipher negotiation. Every system that negotiates has been a disaster.
If I were an intelligence agency or signal intelligence, I might argue for this so that I can narrow my attacks to one cipher. Perhaps the mafia or cartel would benefit from this. I can't imagine any other rational to argue for standardizing on a single cipher.
> NIST have an interesting history around security. One such example would be AES. They favored Rijndael over Serpent, despite Serpent clearly winning on technical merit.
Rijndael won because cryptography is first and foremost a discipline that makes tradeoffs between usability and security. A security measure is not helpful if no one uses it, either because it's a pain in the ass to configure or because it increases your own costs to implement and use. Serpent is technically more secure because it uses 32 rounds of encryption (among other things) while Rijndael uses 10, 12 or 14 (depending on key size). But they're both substitution-permutation networks, and Rijndael is secure enough while offering a significant speed increase. There hasn't been a meaningful cryptanalysis on Rijndael since it was published.
> You can even use this to defeat keyloggers. Open up a prompt that you can type in, then type a bunch of a character. Then use your mouse to select the number of characters that represents your buffer character length, or a portion of it. Then copy-paste as required. Keyloggers will capture cntr-v but they won't capture how many characters you selected.
I don't really follow. If a keylogger has compromised your machine, you're already approaching worst-case scenario territory. More importantly, of course a keylogger can capture how many characters you select. Even if they didn't, they can just capture exactly what's in the browser form field before it's sent in the login request.
> For those concerned about password managers: Leave off something, somewhere in your password.
I like the idea. So what you suggest is to manually type, say, "7&>>", before or after every password entered by the password manager? Or to copy-paste the "7&>>" from somewhere.
A password manager is essential for good security (and I use one) but I'm concerned that it can be devastating point of failure. It can be worse for highly-organized people who keep absolutely everything in there.
It's a single, up-to-date database in a nice standardized format with known filenames and clearly labeled data that lends itself to automated malware that can seek it out when your password manager is open/mounted/decrypted.
As you said, a majority of folks won't be bothered, but a good extra step for someone highly security conscious.
If malware has compromised your device, there is nothing you can meaningfully do to improve the security that is already offered by a password manager. This scenario is right up there with physical access to the machine - you're already screwed.
To comment on this specific example - if you add the same set of characters to every item in a password manager, an attacker can deduce that it's a common obfuscation method.
Why even bother with these weird rules? just use a password manager, generate a secure (> 128bit entrop) password, and be done with it. Also, keepass has something like your keylogger foiling method, called "2 channel obfuscation".
Use whatever option you are comfortable with. I know people that can't bother to use more than 1 password everywhere and certainly can't use more than 6 characters.
This is great, unfortunately considering this is only draft I imagine it will be a considerable amount of time to trickle down through the "compliance standards" we are required to enforce. I do look forward to the day I no longer have to change my password every 30 days though.
I would say that the main reason for periodically changing a password is to be better protected from data theft in those who store the password (read yahoo hack and family).
"In addition to ditching the requirement for regular password changes, the NIST is also advising sites to allow users to create passwords that are at least 64 characters long and include spaces so people can create pass phrases that may be easier to remember and to ditch special character requirements."
Uhg, ibtimes is one of those annoying sites that autoplays video.
There is chrome plugin that blocks autoplay for video and audio, but you then have to give it rights to access all data on webpages. How does this square with with online purchases where you put your credit card in?
In my experience, the vast majority of everybody is still bumbling ahead with post-it notes and simple, memorised passwords shared all across the board.
The first reasonable statistic that I could find was 1%, for the percentage of individuals in a large organization that used password managers [0]. Or maybe it's 8%, in a survey [1]. That 1% figure is pretty old, and people lie in surveys, so it's possibly >1% and <8%.
The vast majority of people don't use password managers (or 2FA).
Anecdotally, I've had good success forcing longer passwords while at the same time, introducing people to password managers. Doing only one or the other does not have the same uptake but we recently went through and forced everyone to reset their passwords. We're now up to 16 chars, I'd like to get to 30 (or to a point where it's a pain to type it in) but baby steps, I suppose.
We took a different approach at my last job when we revisited our entire identity management approach. We were a University with Federated logins across a few dozen system, and our password rules had honestly spiraled out of control because the system hadn't been constructed in such a way to restrict access easily.
During the rework, we focused on a few things primarily:
1. Reduce password complexity, enforce legnth
2. Restructure account creation around least-privilege principal, so that access had to be granted, not just created during account creation, and also allow fast and easy addition and removal of access to system as part of the Management System
3. Revisit password expiries based on level of access and relative strength of password (as determined by zxcvbn)
Students and low level staff loved it - if you had a standard account and didn't have any access to anything sensitive that didn't belong to you, your password could sit untouched for up to 2 years I think if it met the strength requirements.
Those with access to actual sensitive data (student records, finances, etc), were held to a higher class of password complexity and would suffer a rotation penalty if they didn't have a sufficiently complex password; this mostly did away with the number of people with very common passwords, though it didn't go without a lot of fighting for some of the administrators, which, as I remember the discussions anyways, were more pride issues than anything. We used that as an opportunity to roll out password managers
Even if it's the latter, they're actually thinking about what they're trying to protect and what system would work best to protect it. That has got to be an improvement on the mindless, cargo-cult approach to security that most organizations take.
Why do you think it's silly? There are only two reasons to change a password:
1. The cover time (expected duration of secrecy) is about to expire, either due to advances in technology or because it was too small to begin with; or
2. The password was compromised and is no longer secret.
If a password has not been compromised and is sufficiently strong as to not be crackable without a server farm and hundreds of thousands of years, it doesn't make sense to change it.
NIST is acknowledging that the typical user when faced with a password policy that requires a regular password change will choose a weaker password. NIST is advising against imposing a requirement to periodically reset passwords.
Maybe I'm nitpicking but the title as it currently stands is misleading in my opinion.
reply