I feel like this post was intended to inflame or shock the reader with the writers stance on password policy. But anyone who has been in security for more than 1 month knows that regular password rotation has not been a recommendation for over 5 years. Both NIST, and MS have been trying to get the world to move to long, never rotated password, so long as those passwords are dictionary checked.<p>Every company (all 3 of them) I have worked at within the last 10 years, the IAM team has already implimented, or was working on implimenting a system that removed regular rotation, special chars and number requirements, and relied on three things: Length, a dictionary check at the time of pass creation, and routine dictionary attacks against the credential store. This started 10 years ago, for someone to make the same claims now, is not a shock.<p>Please note that if you are unable to impliment such an IAM system, especially the inability to dictionary check the credentials against known lists (seclists' github is great for this), then length plus regular rotation is still the recommendation
One missed point, the advice is even slightly better than they argue, since they only argue that it's not <i>necessary</i> to change it, which is just an argument of convenience.<p>But updating a password is itself an attack surface. More so than merely using it to log in.<p>It's one of the times where an attacker may be tricking you into giving it to them, either by a fake page or app dialog, or in concert with maybe they have a way to receive the verification email or text.<p>Also it's a less frequent operation, meaning it's easier to fake. You are more likely to notice any tiny discrepency and detect a fake in the way your normal login screen looks than some account management screen.<p>Basically updating a password is a riskier action than the normal daily use of the same password.<p>And that alone is it's own even stronger argument for avoiding doing it unnecessarily.
In the USA, the latest government guidance from Jan 2022 is that "Password policies MUST NOT require use of special characters or regular rotation". [1] This is a strong upgrade from earlier softer language like "don't have to/should not".<p>In practice, this new rule contradicts almost every InfoSec stance out there, but all government agencies must comply with this new rule by the end of the year, so expect lots of conversations and changes.<p>[1] <a href="https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf" rel="nofollow">https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-0...</a>
Approachable summary at <a href="https://www.bastionzero.com/blog/i-read-the-federal-governments-zero-trust-memo-so-you-dont-have-to" rel="nofollow">https://www.bastionzero.com/blog/i-read-the-federal-governme...</a>
Perhaps surprisingly, US government guidelines exist, are pretty fantastic, and agree with the author:<p><pre><code> Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed.
</code></pre>
It's called NIST 800 63-B and available here: <a href="https://pages.nist.gov/800-63-3/sp800-63b.html" rel="nofollow">https://pages.nist.gov/800-63-3/sp800-63b.html</a><p>Shameless plug - I'm the cofounder of Clerk and we handle passwords in a sane way out-of-the-box: <a href="https://clerk.dev/features/passwords" rel="nofollow">https://clerk.dev/features/passwords</a>
Worth keeping in mind that passwords do actually leak. Companies have had incidents where they were inadvertently logging secrets passed to them. I've also typed/pasted secrets in the wrong field, which can get into some database or user-interface tracking tool. I've typed my sudo password instead of a vpn password at the command line, thinking sudo login had triggered when it was instead cached. Who knows when these crumbs might turn up.<p>And as others pointed out, breaches aren't always known or disclosed. Is it too late if you change your password 6 months after it's compromised? Not sure - maybe people sit on their exploits sometimes, or wait for a better buyer, or sell secrets in small batches.<p>All that said, I've never changed a password when it was newer than 5 years old, and only do it for crucial services, but if I were a bigger target, I might do it more.
Whenever I talk to people about security, I give a simple thought experiment:<p>Assume the passwords for all of your users are public. Doesn't matter how it happened. How are your users protected?<p>The moment that people go down this road of thought everything gets a lot better.<p>1. How do you restore accounts that may have been taken over?<p>2. How do you detect logins that look like normal behavior vs those that don't?<p>3. Is a password alone enough to get them in?<p>If you address those 3 things everything gets A LOT easier for you and your users.
I am in the camp of requiring people to have strong passwords, and not requiring them to be changed - ever.<p>When you ask people to remember too many passwords, they start writing them down and/or forgetting them, which leads to other problems.<p>My oldest online account - btw it is a brokerage account at one of the big brokerage houses, where a great deal of my cash and investments sit - has not asked me to change the password in close to 25 years, which I find quite funny.
A lot of users will simply change their passwords by appending a 1, 2, 3, etc. at the end. Presumably if old passwords did sour and become compromised then Hashcat would easily crack the minor tweak on the new password.<p>To be fair to these companies, the reason they do passwords so terribly is because of such poor guidance and standards in the past. Even now NIST has SP 800-132 for guidance on generating a cryptographic key from a password for storage applications, which is different and often confused with guidance on storing passwords (which they don’t give advice for). There they say to use PBKDF. Also, compliance standards such as PCI don’t allow for modern storage like Argon2, so at best companies use something like bcrypt.
> Unless there’s a security breach where it’s stored<p>These can go undetected. Imagine<p>1. Hacker dumps database with your username & password in it
2. Brute-forces the database offline
3. Logs in as you / Sells it to 3rd party that logs in as you<p>A lot of time can pass between these steps. Changing your password is a mitigation against this scenario.
One thing people seem to forget is that if passwords are long and too complicated to be remembered then thave to be written down somewhere, a password manager is all your eggs in one basket.
Lose access to your password manager and you can't access any online accounts with unrememberable passwords. Depending on the use case, a rememberable password is often a better option. One you can easily type on a phone is often a priority. My WiFi passwords are long lowercase no spaces word combinations, that are grammatically incorrect. Easy to remember and type on phones or WiFi printers. Most websites won't allow that.<p>I find sites that ignore my opinion on password security annoying. Some sites I just don't use because of their password policy.
You won't necessarily know about every leak. If a security camera records you typing in your password (or you accidentally hit view password in your manager) today someone might find that recording and access your account two years from now. Resetting your password resets the buildup of these small information leaks that occur over time.<p>Best practices get better over time. Maybe two years ago that password was stored as an MD5 hash, and that hash was getting leaked to log data. Bank.com has since fixed that problem, but you don't get the benefit unless you change your password.
Assuming a single character has something in the order of 100 possible values (I.e. a US English keyboard, no Unicode etc.) then a 12 character random password would take about 11.5 days to crack if you had a billion machines that could each crack a billion passwords a second.<p>Assuming NTLM hashes you can currently crack almost 100 billion hashes per second on a single AWS p3.16xlarge that costs $25/hour to run (<a href="https://www.thesecurityfactory.be/password-cracking-speed/" rel="nofollow">https://www.thesecurityfactory.be/password-cracking-speed/</a>)<p>I.e. you’d need 10 million hours of these machines to try every combination possible, with an average time to crack of 5 million hours. I.e. a total cost of $125 million, although I bet you could negotiate a pretty good AWS discount and/ or build the servers yourself and optimize them for cracking, so let’s call it around $50 million to crack a truly random 12-ASCII character password today.<p>Assuming Moore’s law improvements and improvements in energy costs/ efficiency and we can reasonably assume this cost could roughly halve every 18 months, to under $1 million in a decade. That’s not a lot of money to a nation state actor, so if you’re in a position where you seriously worry about active attacks against you specifically, perhaps using passwords that are longer than 12 characters is worthwhile.
IMHO almost all organizations have terrible password policies. There are only a few requirements for a good password:<p>1. The password must be difficult to the point of impossible for a computer to guess.<p>2. The password must be memorable enough that a person can create it once and then remember it a month later.<p>If you don't satisfy requirement #1 then it will be hacked with a GPU farm. If you don't satisfy requirement #2 then the users will undermine your security in a multitude of ways. Almost no corporate password policy attempts to address or even facilitate option #2. They don't even mention it! Many corporate password policies are actively hostile to option #2, requiring a bunch of stuff that's hard for people to remember but only reduce the search space for the computer farms attacking your leaked password database.<p>I like to use phrases made of things that sound like words, but aren't in the dictionary. Make them themed to be memorable. I call them Jabberwocky passwords. Were it not in famous poem a good password would be "mimsy were the Borogroves".
While it is certainly correct to never enforce changing a password, I would argue that it is totally okay to expire it in certain scenarios.
When my company set up the Active Directory f.e. we put a LSA password filter[0] in place that checks against HIBP. The password policy was set to expire every 90 days, atleast 15 characters and dont enforce a history. The non existent history was clearly communicated and users are encouraged to just enter their existing password three times when it expires. That way there is only one place where the passwords are checked for leaks and they are already there in plain, so it is manageable and doesn't add that much attack surface.<p>[0]: Something like <a href="https://github.com/fblz/PassFilter" rel="nofollow">https://github.com/fblz/PassFilter</a> or <a href="https://github.com/rlabolle/hibppwdflt" rel="nofollow">https://github.com/rlabolle/hibppwdflt</a>
I’m not sure that this article sufficiently addresses the following natural objection: I don’t always know when my password has been leaked, and the chance of it having been leaked increases with time, so I should change my passwords ( to new strong, unique values) to lower the chance that they’re compromised.
For people who have to change their password regularly I suggest just adding the month and year in numbers at the end of whatever password they like to use. That way there is a clue in the current month and year as to what their password probably is should they forget
And when do you know that said passwords have been breached?<p>Companies RMA, sell off, donate, and/or dispose of older drives, RAID caches, computers, workstations - are you 100% sure everything was DBANed properly without any data still lurking in bad sectors? All it takes is one snoopy fellow dumpster diving, or going through the garage-saled hardware of your former IT guy who made backups, finding some hardcoded credentials on an unencrypted or poorly encrypted drive - or other similar act of stupidity - to potentially leverage mistakes made years ago into active network access.<p>As annoying as I find password rotation, I get it.
"And not breached" is the key there.
Passwords are breached all the time, usually without notification.
See services like 1Passwords Watchtower, or look manually at lists like haveibeenpwned.
I think organisations forcing people to change passwords causes greater security risks. For example - if you have a bunch password character and length requirement, you will find people writing their passwords on paper or being more flexible in storing them. Because of this frequency, people will forget their password often and require assistance of IT admins or other people often through phones and emails.<p>I would say, strong password is slowly becoming a myth due to organizations failing understand what it is before creating a policy surrounding it.
I imagine a world where governments get together and mandate that all online passwords use the same standard of password requirements and salt/hashing at the backend. Penalty should be 10% of your gross revenue.<p>While they are at it mandate some standards of customer service if your business exceeds $1M in gross revenue (must have a "get human" button and the call hold time shall not exceed 15 minutes).<p>I know that sounds like a fantasy utopia, but I remember a time in the 70s when there was a serious push for consumer advocacy in the US.
> some organizations want to convince us that with the passage of time your password becomes increasingly susceptible to attack<p>I feel like this is somewhat true for self-fulfilling prophecy reasons; these same organizations don’t always disclose every compromise or leak of their systems, and don’t always force a password reset when it happens because it would reveal they’ve been hacked. I’m certain I have multiple online accounts at organizations that have suffered minor, major, and ransomware level breaches.
So, really, you <i>should</i> change a password regularly if:<p>- The password is weak<p>- It is ever reused<p>- Anyone else has access to it<p>- You use it on a device you don't control<p>- You use it on a device which might be running malware and can intercept it<p>- It was stored insecurely
This is good for developers but there are two important unknowns if you're an end user:<p>1) You don't know whether the service or site employs best practices e.g. throttling. (Although you might be able to test that yourself if you're tech savvy.) So you may have to assume the worst, and there goes Point 1.<p>2) You can't be sure they will report a breach if it occurs, or that the password will ever show up in e.g. haveibeenpwned. So there goes Point 3.<p>Point 2, you do have control over.
> not breached<p>Which a consumer of a service does not know. There's law now to force providers of services to announce leaks/breaches and there's haveibeenpwned; both are no guarantee.<p>Changing a password gives consumers a fresh start.<p>> Passwords do not age. They do not sour, spoil, or stale.<p>The "fresh start" does imply some sort of spoiling/ageing.<p>Rotating passwords (re-freshing) in the age of password managers is not that much work, for some critical accounts that may be a good thing.
I use Password Safe, an open-source password database.<p>I highly recommend it for people that are more computer savvy. For the digital illiterates OnePass may be more suitable.
#PREACH!<p>the Hive infograpgh (amongst others) always comes to mind; 18 characters long, upper, lower, numerical, special. estimate time to brute force 438tn years.
> Robust, unique and not breached<p>What? If they're not breached then that invalidates the other two points anyway - unless you can find an authentication endpoint that doesn't rate limit. HTTP proxies are expensive and trying to brute force something that is on-server is not a common attack vector.<p>I know its nit-picking, but the title is incendiary and warrants that.
It's all right there in NIST 800-63-3 <a href="https://pages.nist.gov/800-63-3/sp800-63-3.html" rel="nofollow">https://pages.nist.gov/800-63-3/sp800-63-3.html</a><p>Big takeaways:<p>Longer passwords.<p>No hard requirement of symbols.<p>Passwords don't change unless its in breach notifications online<p>Regular scanning of breaches for hacked login/passwords or commonly used passwords
What about an undetected data breach leaking username and passwords? Periodic password replacement reduces the window where someone's stolen password is used a long time after breach. This may not be the threat scenario for every type of accounts, but in some type it would one among the most important ones.
Here's a good and free tip: A unique password breach can be turned around to better know your enemy. Set-up a canary honeypot and monitor your environment for it:<p>See <a href="https://github.com/thinkst/opencanary" rel="nofollow">https://github.com/thinkst/opencanary</a>
I've been saying this for years.<p>Whoever came up with the idea that passwords need to be regularly changed must be shot because no one has ever proved it makes any sense.<p>What it actually does is that people write passwords everywhere (papers, text files, etc), thus actually lowering their security.
One problem with this strategy is that you never know if there has been a leak. Proactively changing passwords protects against such leakage, such that the leaked password must be used within the window where it is still valid.
I suggested my co-workers, at least half-seriously, that upon mandatory password change the old password should be added to an internal website.<p>That seems like a good way to ensure people don’t use stupid passwords: public embarrassment.
Possibly contrarian point of view:<p>a) Passwords should be easily rememberable. Pick four words are string them together (e.g. correcthorsebatterystaple).
b) You must have a physical security key to authenticate - a Yubikey etc.<p>If those two factors are not enough, then forget working from home / mobile authentication - require people to arrive in-person and work in-person, with network restrictions on top of the two-factor authentication.<p>If two-factor authentication isn't enough, and IP address restrictions aren't of help to enforce know-your-user when they show up in person, then I swear, God help you. At that point, you're no longer practicing security, you're practicing paranoia.
> There’s no need to change passwords if they're robust, unique and not breached<p>This assumes you'll know if passwords were exposed in a breach. Some breaches go undetected.
I encourage everyone in a position to run into this discussion internally to memorize a few key sections of NIST 800-63. It's come in handy more than once...
A problem of passwords is how do you know when a password has been breached?<p>The beauty of public key authentication is that there's nothing to breach on one side.
> Unless there’s a security breach where it’s stored<p>But how confidentally we know this. Hence, people periodically change password. Or am I missing something?
There is still a specific case for password rotation which is to periodically rule out the threat of compromised passwords.<p>Meaning, if your password is 10 years old it's subject to any leaks or security events during that long time frame. If it's 3 months old, anything that could have happened to it must have happened in the last 3 months which is much better than 10 years.
I hate password rotation rules. Companies have iT departments that love nothing more than to add "value" by adding their own spin on what password security should be. It's pure security theater.<p>At every company I've ever worked that required password rotation, everyone just incremented a digit, usually at the end.<p>I also hate the completely arbitrary rules on length (I mean, why do some sites have a <i>maximum</i> length?). Some require uppercase and lowercase as well as digits and certain special characters and what special characters are allowed is inconsistent and completely arbitrary.<p>We need to focus on how much entropy [1] a password has without arbitrary rules. 20 lowercase letters is going to be better than a 7 letter dictionary word with one letter capitalized and a number of symbol on the end. In fact pretty much every password 8 characters of length should be considered cracked. 10 should probably be the absolute minimum.<p>[1]: <a href="https://xkcd.com/936/" rel="nofollow">https://xkcd.com/936/</a>
The tldr of this post:<p><pre><code> What Should You Do?
There’s a simple checklist of improvements you can make to keep your passwords forever secret:
If you aren’t already, start using a password manager.
Use the password manager to generate strong, unique passwords for every account.
Review old accounts that contain personal, proprietary, or financial information and update their passwords using the password manager.
Never share personal facts, like your pet’s name, when required. Instead, replace a real fact with random text that you store in your password manager for later access.
Enable two-factor authentication wherever available.
</code></pre>
I can't argue with any of this! But there are obstacles on the path to this utopia. Password managers are becoming more and more usable for average folks, though I've seen some confusion in some of my non-tech friends/family, esp when integrated into browsers. There's also the question of market penetration. Is your grandma going to use a password manager?<p>Other trends I've seen:<p>Passwordless auth tying into WebAuthN. If a site can tie into a method secured by the OS, all the better. I'm not sure the uptake, but have seen some presentations/comments about it being a far superior UX. Also, seen some startups built (and raising $$$) around just this.<p>Known, trusted bigcos like Facebook (ya, I know, but they are trusted by lots of non tech folks) and Google. This has some upsides because they can secure accounts really well, and also keep on top of new security reqs like MFA. But there're plenty of HN stories about being locked out of these IdPs, so this may be a bit of a scary delegation for some.<p>Passwordless auth tied to email. This is great for low value, infrequently used accounts because often 'send me creds via email' is the default path anyway, usually via 'forgot password' flows.
I am unconvinced. What about persistent password bruteforcing? Rate limits? OK, bruteforcing is happening within those rate limits. That's how the password rots - it becomes less of a secret as many values are tried.<p>Key material rotation seems to be a sensible practice in general.