I update my passwords from time to time. I don't trust the organizations will always say if there is breach, know there is a breach, or actually know how far and wide a breach went.
Do you trust them to salt and hash your password using bcrypt? (rather than store it in plain text). Do you use a password manager to generate strong passwords that are at least 16 chars long? If you can answer yes to both, then it doesn't actually matter if your hashed password was part of a breach or not, the hackers won't be able to brute force it. (Of course if hackers manage to steal the private key with which your session cookie is encrypted, they can still log in as you - but then changing your password won't help either).
This seems reasonable.
How often do you change you passwords?
Feels like it would get extremely tedious if you have more then a few accounts though, no?
This only applies to banking and email passwords. And most last over a year. I don't have a schedule, just one morning I wake up and go, 'oh yea, I've been using that password since 2019...'.
Yes. For sites, desktops, everything that have some rule stating that passwords expires after 30/90/180 days, must not repeat the last 3/5/10 passwords, must have at minimum/maximum n characters, must/must not contain special symbols or some subset of it.
My current work forces updates every 3 months. It seems more like a security issue requiring this reset so often.
This is because they create another problem when anyone you talk to will say they have their password and just increment a number for every password change. That way they’re not having to remember a whole new password every few months. So there’s never much of a change in anyones password during these rotations.
I think this is an issue for things like a system login where you can't necessarily use 1Password or your equivalent. I have my work domain password in 1Password, and it's a huge pain in the ass when I need to use it in that context.
However, if you use a password manager, and have access to it, I think forcing key rotation on a short schedule actually increases security. The downside of course being that most people don't use a password manager, and most people use the same relatively unsecure password for everything.
NIST actually changed their recommendation relatively recently and no longer suggests periodic password changes without reason.
> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
Yes, and I believe they initially made this change in June 2017 (almost 5 years ago now). IT audit/compliance is typically 5 to 10 years behind best security practices and some standards are even slower to catch up.
Yes. You can set your passwords to expire after a date (or a period) in KeePassXC. They will show up in your Health Check reports along with weak or non-unique passwords, possible leaks and more
For certain sensitive websites (e.g. domain registrar) I change passwords once a year or so, because there's really no guarantee that administration would 1) notice a breach early or at all, 2) fully understand the scope/severity, or 3) even notify their users about a breach.
Perhaps surprisingly, US government guidelines exist, are pretty fantastic, and agree with the author:
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.
That’s the key people are missing. There’s a trade-off (though people can easily memorize phone numbers for example) when the password gets to complicated and you have to write it down.
I know it's hard to imagine, but before we all held supercomputers in our pockets we all used to have dozens of ten-digit numbers memorized. I still remember my grade school friends' phone numbers.
You were an extreme outlier if you bothered to memorize dozens of ten digit phone numbers in the era before everyone had a cellphone.
The average person doesn't even have ten good friends, much less a need to memorize dozens of phone numbers. They would buy address books / contact books to write down dozens of numbers, not memorize numbers they very rarely use.
Or even more niche in your outlier status if you could remember IPs of the commonly used servers without a DNS in place.
Most of the time, local networked IPs all start with the same values for the first 3 octets (maybe 2 if VLAN but then usually only one digit diff). The same was true for most people's local phone number memorized registry. Those of us old enough, we only had to dial 5 digits using (70s) the last number of the prefix before eventually moving to 7 digits to include the full prefix (80s). The world suddenly changed when we had to dial the entire area code as well (90s).
I think "dozens" is an overstatement, but 10-20 wasn't unusual. In college, I could have given you the number for a dozen delivery restaurants, easily. Not proud of it, just saying. That's not counting family, friends, services like taxi companies and movie theaters, and work.
How many different area codes did those dozen delivery restaurants and taxi companies have? How many different exchanges? Was each one a unique area code, each a unique exchange? If not, then you're not really remembering unique 10 digit numbers. There's going to be a lot of repeated numbers in there.
I remember 2 out of the 3 landline numbers (one is my parents, still using that) I used to know, my 2 ICQ numbers, and my mobile phone number (which is still the same now, 20 years later). I never felt the need to remember a ton of numbers, that’s what phone books (digital or analog) are for and why I now use a password manager ;)
On top of that, in many areas in the US the time between moving to ten-digit dialing and the time of cell phones becoming even somewhat popular is really only a few years or less. Some places in the US are only finally being forced to move to ten digit dialing with some places still supporting seven digit dialing.
> Starting on Monday, October 25, 2021, Texans with phone numbers in the 254, 361, 409, 806, 830, 915 and 940 area codes must dial 10-digits (area code + telephone number) for all local calls.
Rate limit the requests. Do an account lockout with an email click to re-enable after 10 guesses, do 2FA on new devices and you get pretty good security.
For many systems, users can memorize 6 digits easily.
The reality is, whatever your password reset flow is is enough. If you can reset your password with a 6 digit number via text, then that is maximum needed for actual password as well in most cases.
Interesting. In most cases if hash database leaks, the ability to crack depends on two factors, not one (password and hash difficulty) assuming you are salting properly.
You can specify pretty high difficulty with argon2id etc. Ie, shoot for a one second runtime with a very high memory requirement (you can go to GB range even).
That provides one million possibilities. I don't think you're missing anything. That's pretty terrible.
The only thing prolonging your account at that point is the service's rate-limiting, assuming a naive "enter this password in the login field, try it, repeat."
On the other hand, if you have too many password requirements and the user can’t remember it, they often lean on bad password hygiene, and the password ends up being reused (and inevitably leaked) or written down somewhere.
Rate limiting can be practically strong for everyday use. Bank PINs are commonly 4 digits, though the chip+PIN system allows up to at least 6. Three attempts and the card is locked. Provided you stop users from picking obvious numbers like birthdays, it's pretty effective at preventing card fraud.
Weak passwords can be fine, provided rate limiting is extremely aggressive. You can adjust this based on access e.g. your admin account might be locked under stricter heuristics like a single attempted login outside your geographic region (Live mail does this to me sometimes). In this case the user might even have the correct password, but if something else doesn't add up then you can block.
But if you actually tried to use 6 digits you'll discover most layers never tested it, including some of the most common point-of-sale systems and many ATMs not operated by your bank. Plus, tellers at your bank won't believe you.
My debit card in Switzerland came with a six digit pin - which was a surprise coming from the UK - and it works fine in other countries (Germany and Italy at least). But chip and pin is well known established in Europe so that's not too surprising.
> A rationale for this is presented in Appendix A Strength of Memorized Secrets.
The relevant part of which reads:
> The minimum password length that should be required depends to a large extent on the threat model being addressed. Online attacks where the attacker attempts to log in by guessing the password can be mitigated by limiting the rate of login attempts permitted...
>
> Offline attacks are sometimes possible when one or more hashed passwords is obtained by the attacker through a database breach. The ability of the attacker to determine one or more users’ passwords depends on the way in which the password is stored. Commonly, passwords are salted with a random value and hashed, preferably using a computationally expensive algorithm. Even with such measures, the current ability of attackers to compute many billions of hashes per second with no rate limiting requires passwords intended to resist such attacks to be orders of magnitude more complex than those that are expected to resist only online attacks.
My reading was not that it must be entirely numeric, but that there is no rule that it won't be. As in, an attacker cannot make any assumptions about the characters in the randomly chosen password, such as "well it won't be all numbers, so lets rule out all those possibilities The 6 character limit only seems to apply to randomly assigned ones, not to ones the user picks, which is where a strategy like "what about all the number combinations" is more useful.
Any kind of bias like that is potentially exploitable, though. If the rule allows "only numeric", and that's the simplest thing to implement, then someone's going to implement it that way.
Which means that an attacker now knows that moving "only numeric" to the beginning of their attack sequence may be a viable strategy. Whereas if the rule did not specify, the attack would not be able to make assumptions about the character set.
Re: entirely numeric, as long as the attacker assumes that the victim may use letters in their password, all numbers is fine, it increases the total number of possible combinations an attacker needs to work through
I interpreted it backwards, "if you want to use a numeric keypad for controlling access to something, the codes MUST be at least 6 digits long, and you MUST assign them"
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.
Key material rotation seems to be a sensible practice in general.
With a ratelimit of 60 attempts per minute (which is significantly higher than any user would legitimately ever need) you're looking at thousands of years to bruteforce a random 6 character alphanumeric password.
Yeah and if your system allows an attacker to sustain one attempt per second into perpetuity, then you need to improve your system. Just be wary of DOS attacks against users when considering things like per-user limits (versus per-IP limits)
The problem is that ratelimiting doesn't work when your password database is leaked. Brute force attacks on the front end system basically don't happen because rate limiting is everywhere. They'll try a handful of default passwords and move on.
What you're saying is true, but you need to consider a regular office drone who doesn't care about security. If you require them to change the password every 90 days, you will end up with the majority of people having passwords like conS0t01, conS0t02, conS0t03... And not only will they have such weak passwords, they will boast about this to anyone who will listen, leading users to actually tell other people their password, and how they arrive at (And remember) the current mutation.
And when it arrived at the point user themselves are confusing about "wait, is it end at 33 or 34?". They Will Write It Down On Post It. And you end up get the worst security situation you can get normally.
> it becomes less of a secret as many values are tried.
Not meaningfully. Let's take my Hacker News password and we'll imagine you happen to know (somehow) exactly what the format is, so then you start guessing.
And we'll imagine you can make 1 billion login attempts per second, which in fact I'd guess will make dang pretty unhappy 'cos the servers won't like that.
And maybe you get to do this on a billion computers, and for a billion seconds, again I'm thinking somebody would notice and stop you, but let's just say...
At the end of all that you've still got orders of magnitude less chance of guessing my password, for this web site correctly than a random ticket buyer has of winning the jackpot in a typical state or national lottery game. Get a new hobby.
I think people struggle with the numbers involved. Even astronomical numbers are too small, because astronomical numbers involve practical things, like how quickly light travels and maths does not need to be practical.
"There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers." - Richard Feynman
Yeah it's an obnoxious process. I don't know why people are so against passwords. Use a manager (or at least something like Lesspass), and then you're fine. Passwords aren't scary. They won't bite.
Too many extra steps, especially on mobile. And very suspectable to phishing and social engineering. Also makes it impossible to login if you lose email access (and what if you need to change your address because of it?)
I am very curious why public private key auth is not a thing for websites and applications. I would rather have a single password to the server that publicly hosts my public key then I can simply point websites and applications to that address during signup. Every app/site would check the server every 5-20 mins for changes to my public key in case I need to change it. Then I can use my private key to authenticate to all these sites/apps instead of trying to keep track of 500 damn passwords.
If you're logging in from a library computer, you don't want the hassle of putting your privkey file on it and wiping it later. (Or connecting a USB drive, which may be a security hazard for the library)
If you lose your computer, you still remember your password, but your only copy of your privkey may be lost. Losing hard drives is common for non-power users, because they don't do regular backups, and they often don't know that you can trivially recover files from, e.g. a laptop with a broken screen that won't boot.
And computerized cell phones are actively trying to convince those non-power users that files don't even exist, to protect their profits.
I really hope that password managers are a step in this direction. Once they become ubiquitous then everyone effectively already has a "master password" for all their online identities. It wouldn't even really need to be a 3rd party service. The password managers could hold the keys locally and websites could just use WebAuthn for authentication.
Your idea is basically "What if I was 100% trackable everywhere" which, if you're comfortable with that you're a rare exception - and if you didn't realise that was what you just proposed, well, now you know why we don't do that.
Now, public key cryptography is indeed promising, but you see something rather more sophisticated to deliver privacy and security and that's what WebAuthn is.
It's probably a bad idea to authenticate on a public machine to begin with. How can you possibly know what that machine might do with your account once you log in?
But let's say you want to do it anyway. There is no need to memorize or type the entire key; a site-specific private/public keypair can be derived from a memorized master password and the domain name (for uniqueness) via a KDF. The site never needs to see the master password, so in the event of a breach all your other logins remain secure, and there are no key files to synchronize, just a single password for access to all your accounts.
You do need to trust that the PC you're using to log in is secure, though, since it has access to the master password; I'm not sure how you would get around that without involving some other trusted piece of hardware, and if you have that you could just use it to access the site instead.
WebAuthn can do full blown Usernameless, and it's very easy with devices like a modern iPhone or high-end Android.
I have no idea why this wasn't immediately huge. You see the login button, you tap it, your existing fingerprint reader or whatever verifies you are still you, whoever that is, and you're logged in, done. Much more secure than people's crappy passwords, yet much easier to use even than the crappy passwords.
I am in the camp of requiring people to have strong passwords, and not requiring them to be changed - ever.
When you ask people to remember too many passwords, they start writing them down and/or forgetting them, which leads to other problems.
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.
> When you ask people to remember too many passwords, they start writing them down and/or forgetting them, which leads to other problems.
Writing passwords down isn't the worst thing. If you can't convince someone to use a password manager like 1Password, getting them to use a physical notebook of unique and strong passwords is actually the next best thing, because (combined with 2FA) it protects them against the most relevant threat models for most people (phishing and password stuffing).
A business card stored in a wallet or purse is pretty good too. After all, we're already pretty used to protecting our credit cards, identity cards, and cash.
It's pretty bad to put both a debit card and it's password together.
The only reason it's even tolerable risk to walk around out in the wide random world with a debit or credit card on your person all day every day, is because somewhere else you have the means to disable it and declare it lost.
This is like storing the keys to your car conveniently right on your car.
That's an important corner case I overlooked. I still think it's easily solved using the same principles: there are places in our houses where we regularly store sensitive items in already as well, such as a filing cabinet, or key safe, or next to that emergency $100 in a book.
Writing passwords down is inevitable. Having to remember more than two truly strong passwords is a ridiculous requirement to impose on the general population, and we live in a world where we need access to dozens of different accounts which ideally are supposed to all have different passwords.
We either need password managers or we need to do away with passwords entirely.
I will go further, expecting people to remember single strong password and change it every 3 months and not write it down is too much. Because after literally three rotation people will confuse previous and current password. And they will be out of memoizable ideas.
Your money is insured, your brokers are insured. They just manage the risk differently than people directly in the tech world. Even though banks are right in the middle of it.
A good analogy for banks risk mitigation is like putting up a guard rail in front of a cliff. It's up to the user how high the rail gets set. Like daily limits, notifications, initial passwords, 2fa etc.
For the most part, banks and brokers want to reduce the friction of events.
I worked on a crypto-related project where we ended up just generating a strong password on the client during registration. Credential stuffing attacks are just too effective.
Nobody complained. I think it's a better solution than making the user come up with their own strong password with annoying special character rules when you can just generate one for them.
The interesting challenge was making it work well with all password managers though which often have mind-numbingly dumb heuristics about what could possibly be a password field. It's worth a blog post.
>Idea about rotation of passwords is that you assume that your password 'was leaked/cracked' and you don't know about it and have no way knowing it.
That's really not the user's responsibility at that point. It's up to the service to store passwords securely (i.e., use proper password hashing functions) and monitor login behavior to throw up extra challenges if things look suspicious.
Password rotation is a high-cost measure placed on the user that has little (even negative) benefit, especially when there are more effective alternatives the service is better-positioned to implement. Users cannot twist themselves into knots to make up for shitty service-side design decisions.
When I have right of way on the crossroads and I see truck coming with high speed from the side I am not going to drive in front of it and then claim, it was his responsibility to stop because I had "right of way". It is also no use when I am dead or severely wounded or all my money from account gone.
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".
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.
The "character class" requirement really doesn't add much security. And the "password rotation" policy can actually result in worse passwords than otherwise. Those measures were effectively just folk medicine from the days when the threat was thought to be someone manually trying to brute-force your password at your terminal.
> The "character class" requirement really doesn't add much security.
If you're generating your passwords randomly (using a password manager) it actually reduces security because it reduces the set of acceptable passwords.
That might be the only way to guarantee secure passwords across a platform/company. Of course, then you have to make sure people don't write it on sticky-notes under their desks...
Requiring special characters also reduces the set of allowable passwords by eliminating all passwords that don’t contain at least one special character. The best practice for maximizing the set of acceptable passwords would be to allow, but not require, special characters (and to allow as many of them as possible, not the narrow subset of special characters applications often allow).
Like how the Nazis thought they were so clever for preventing the enigma machine from repeating letters in the output. You’ve just reduced your entropy, sucka !
You're probably right that, in practice, the character class doesn't automatically add security if the password is sufficiently strong and random. The theory is that by introducing special characters you're decreasing the likelihood of having characters that are commonly found together, thus decreasing the effectiveness of dictionary attacks.
Of course modern dictionary algorithms will still look for characters that are commonly used as substitutes for letters ($ = s, # = h, ! = 1 etc.) so really you just want your password to be random, long and unique.
The NIST guidelines address that in a much more straightforward way: maintain a list of known bad passwords (e.g., HIBP) and prohibit users from using any of those. Character class requirements are pointless.
Not to mention it makes it harder to use the password in automated systems, as lots of places try to parse (or can't encode properly) $, /, -, and others.
I worked on Identity, Credentialing and Access Management (ICAM as it's known) in the Federal space for a while.
The U.S. Fed Gov has been implementing MFA with smart cards since 2001. While there are pockets of ineptitude and resistance, the vast majority of government employees and contractors use a hard token second factor.
Security is a property of a system, so analyzing a particular password policy outside of the given context (mandatory hard token MFA) is nonsense.
Yes, and the latest Zero-Trust guidance is actually legitimately good - it enforces a security practice on all gov agencies that will be better than 99% of the private sector. The password policy is just one line, but still a welcomed slap on the face of all Old Guard folks (who are overrepresented in infosec policy-making). The rule is clear: MFA or GTFO.
In practice, when dealing with US auditors and infosec chiefs, saying that "Some researches/guidelines say X is not necessary" will not compel anyone to change because "This is always been this way, and it doesn't _hurt_". The conversation becomes categorically different if you say "The White House says X is not allowed anywhere."
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.
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.
This is literally what I did at my last company, where we had to change our passwords every few weeks. It was so damn frustrating. I'd be fine memorizing a random string of text, but having to constantly change my passwords meant that I'd continuously get locked out until I did that.
For my own personal use, I just use a password manager + randomly generated passwords, but it seems corporations are so damn slow to pick up on these obviously beneficial things that they choose clearly antiquated standards instead.
Anything below 5 in distance gets rejected, try again, please.
While you get to change password you make 2 boxes with current and new of course and do your comparisons on it, just to explain you still keep passwords hashed.
> Unless there’s a security breach where it’s stored
These can go undetected. Imagine
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
A lot of time can pass between these steps. Changing your password is a mitigation against this scenario.
The correct mitigation for these scenarios, which I agree are a problem, is to not use shared secrets. Key rotation/ changing your password is a poor workaround.
If you steal the WebAuthn database from my toy implementation, now, or tomorrow or ten years in the past, it makes no difference because it doesn't have any secrets in it, so, you don't learn anything useful. "Man, if I was this web site, which I'm not, now I could validate that the authentication was successful".
In such schemes the only thing similar to a "secret" is the Private Key, which exists only briefly temporarily inside my Security Key or other authenticator when it is doing its thing.
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.
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).
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.
We effectively have this now with PCI-DSS (requirements imposed by credit-card processing companies), and it sucks because of the bureaucracy involved in making any change.
It has take literally over a decade to relax the requirement for password rotation from 3mo to 1yr for employee accounts of companies that process CC payments, despite industry knowledge and formal studies saying that frequent password rotation was detrimental and useless.
Instead of defining the process, state the outcome you want and set penalties on failing to meet the outcome.
E.g. "don't have password leaks, or it will cost $1k per account paid directly to the account holder" (or your percent of gross, split among leaked accounts). Let companies implement those controls however they wish, as long as they are achieving the outcome and penalties are actually being applied.
I agree that failures need to have significant penalties, otherwise companies will decide that the penalty costs less than the prevention (which is true today) and minimize their investment in security.
the Hive infograpgh (amongst others) always comes to mind; 18 characters long, upper, lower, numerical, special. estimate time to brute force 438tn years.
not OP but I only have to remember two 18 character passwords, my laptop and KeepassXC. I use all of OP's suggestions as well as mixing languages, one being an indigenous language that only about 20K people in the world know, together with a little leet speak. I haven't been breached since the early 2000's.
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
If you're worried a password will leak, how frequently should you rotate it to maintain security? e.g. Even rotating yearly still seems a chore if you do it for websites you don't frequently visit (such as sites you made 1 order from).
The "add YYMMDD" or whatever is a way of working around a policy which automatically enforces a more frequent rotation than you want.
My security policy is based on the most common data breaches, where an adversary obtains a big list of email/passwords and just tries them on a handful of sites (Facebook, Twitter, etc), throwing out the records that don't work.
Sure, it's technically possible to decipher the algorithm[0] I use to generate new passwords, but that's not what I'm protecting against. If someone is trying to attack a specific person, there are much more effective ways[1].
[0]: For example, if my password for HN is "1y2c3o4m5b!$", you could sit down and figure out my reddit password.
Oh yeh it’s not ideal but the alternative is my relatives having a post-it note nearby with their current password written down - I feel this is a lesser of two evils
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.
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.
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.
If you do not reuse passwords and one of them does leak, then the only thing affected is the site/service that was compromised. Hence the word "unique" in the title.
That is true, but that one secret is still at risk, and maybe that secret means the world to you. You don't know when the info will be discovered or change hands. "No need to change" could maybe be nitpicked even though I agree with it in general - changing seems to provide some marginal probabilistic benefit if done properly, and the cost/benefit probably depends on what you are protecting.
Scenario: Your device has a keylogger. It already happened that e.g. android device makers were overly aggressive in debug logging almost everything, including everything you type or paste on the clipboard.
Leaking a password on your side is an unknown unknown, so password rotation is not a bad practice on its own for a security conscious person: It limits a leak in time.
Mandatory password rotation is a whole different kettle of fish, as it pushes users to lower password quality. Infosec policy was required to balance 2 conflicting needs, and the past has thougt us we balanced wrong.
I think it's also worth pointing out that there are many reasons why 2FA is valuable. Even if someone ends up with your password, they would still need your second factor, which could be a TOTP token or a WebAuthn device like a YubiKey.
Even if you rotated your password frequently, there would still be a large window of compromise. Password rotation only helps with very strange attack scenarios, and passwords themselves aren't really good enough for anything where security actually matters.
I would personally push away from passwords on the whole at this point. SSO is probably more secure for most users. Plenty of websites only support username+password auth, and given how bad most passwords are... I might even go so far as to suggest that username+TOTP is instantly more secure than that, especially with proper rate limiting as you should have anyways. (Yes, I know TOTP is "supposed" to only be a second factor.)
WebAuthn takes this to the next level and promises a future where you can use a strong single factor to log in, without any opportunity for phishing or credential compromise... but most implementations I've seen still require a fallback password mechanism. There are understandable reasons for this right now, but it is unfortunate.
If your old password was compromised by a keylogger, your newly rotated password will be too.
There original threat model for forced password rotation was supposedly based on hash cracking time. This is a stupid threat model; the guy from NIST who wrote it back in the 80s admitted it was based on no research but was added arbitrarily because it sounded good at the time.
> Is it too late if you change your password 6 months after it's compromised?
I'd say no... some compromises are "2 step"... Ie. someone accidentally was logging the passwords in plaintext for a few months to some logs system (compromise 1)... and then years later some attacker breaks into the logs system (compromise 2).
Or you accidentally typed a password into a terminal and it got stored in your .bash_history... and then months later you accidentally make your dotfiles github repo public, including your .bash_history containing your password...
Also, some thieves may compromise your account but not do much evil with it (and remain undetected). And then many months later they sell your account to someone else who does do evil with it.
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.
If it remains undetected, the rotated passwords will still be leaking. Once you detect and mitigate it, you force everyone to reset their password immediately. Periodic password rotation is pointless.
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.
One missed point, the advice is even slightly better than they argue, since they only argue that it's not necessary to change it, which is just an argument of convenience.
But updating a password is itself an attack surface. More so than merely using it to log in.
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.
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.
Basically updating a password is a riskier action than the normal daily use of the same password.
And that alone is it's own even stronger argument for avoiding doing it unnecessarily.
Agreed. I think the main new vector is a "new device". So having the user approve on an old device (where possible or otherwise use 2FA) would prevent most of the log in attacks. It also removes the attack of "look under the mouse pad" where bribing a cleaning person gets you a whole company's user logins.
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.
At every company I've ever worked that required password rotation, everyone just incremented a digit, usually at the end.
I also hate the completely arbitrary rules on length (I mean, why do some sites have a maximum 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.
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.
I use parts of song lyrics or movie quotes for most my passwords, and I do the same with increasing a digit. I'm at digit change 17. The thing that REALLY kills me is when a password has a maximum length.
It's vastly more likely you'll be pwned by remote passwords than local programs. Even if it is a local program, there's so many ways to store a password there's no automated way to reliably get a password. Your threat model will become a person targeting you specifically, thumbing through your files to find information, etc.
While sharing passwords is never a good idea, sometimes it is necessary. For example, I am the treasurer of a non-profit organization, an elected position that rotates every two years. We have a savings account at a credit union that for a variety of reasons requires online access by multiple individuals who change over time. The only way to keep this even a little secure over time is to require a password change every time someone drops off the authorized access list.
There could also be software licensing issues that lead to multiple users sharing a login for software, same thing applies.
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...
287 comments
[ 2.5 ms ] story [ 236 ms ] threadThis is because they create another problem when anyone you talk to will say they have their password and just increment a number for every password change. That way they’re not having to remember a whole new password every few months. So there’s never much of a change in anyones password during these rotations.
- abcde1 - abcde2 - abcde3 - …
However, if you use a password manager, and have access to it, I think forcing key rotation on a short schedule actually increases security. The downside of course being that most people don't use a password manager, and most people use the same relatively unsecure password for everything.
The policies are the problem and the industry has recognized it so they’ve moved away from those recommendations.
> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
Source: https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver
https://keepassxc.org/blog/2020-08-15-keepassxc-password-hea...
Shameless plug - I'm the cofounder of Clerk and we handle passwords in a sane way out-of-the-box: https://clerk.dev/features/passwords
The average person doesn't even have ten good friends, much less a need to memorize dozens of phone numbers. They would buy address books / contact books to write down dozens of numbers, not memorize numbers they very rarely use.
Most of the time, local networked IPs all start with the same values for the first 3 octets (maybe 2 if VLAN but then usually only one digit diff). The same was true for most people's local phone number memorized registry. Those of us old enough, we only had to dial 5 digits using (70s) the last number of the prefix before eventually moving to 7 digits to include the full prefix (80s). The world suddenly changed when we had to dial the entire area code as well (90s).
Area code was likely all the same, maybe 2-3 tops, and associated both with the following exchange and geography, and used extensively.
Exchange, also likely all the same, maybe 6 at most, and again likely associated with geography.
https://www.kcbd.com/2021/10/12/new-10-digit-dialing-procedu...
Note the date on this: Oct 2021!
> Starting on Monday, October 25, 2021, Texans with phone numbers in the 254, 361, 409, 806, 830, 915 and 940 area codes must dial 10-digits (area code + telephone number) for all local calls.
For many systems, users can memorize 6 digits easily.
The reality is, whatever your password reset flow is is enough. If you can reset your password with a 6 digit number via text, then that is maximum needed for actual password as well in most cases.
You can specify pretty high difficulty with argon2id etc. Ie, shoot for a one second runtime with a very high memory requirement (you can go to GB range even).
So I'm not sure all is always necessarily lost
The only thing prolonging your account at that point is the service's rate-limiting, assuming a naive "enter this password in the login field, try it, repeat."
Weak passwords can be fine, provided rate limiting is extremely aggressive. You can adjust this based on access e.g. your admin account might be locked under stricter heuristics like a single attempted login outside your geographic region (Live mail does this to me sometimes). In this case the user might even have the correct password, but if something else doesn't add up then you can block.
> A rationale for this is presented in Appendix A Strength of Memorized Secrets.
The relevant part of which reads:
> The minimum password length that should be required depends to a large extent on the threat model being addressed. Online attacks where the attacker attempts to log in by guessing the password can be mitigated by limiting the rate of login attempts permitted...
>
> Offline attacks are sometimes possible when one or more hashed passwords is obtained by the attacker through a database breach. The ability of the attacker to determine one or more users’ passwords depends on the way in which the password is stored. Commonly, passwords are salted with a random value and hashed, preferably using a computationally expensive algorithm. Even with such measures, the current ability of attackers to compute many billions of hashes per second with no rate limiting requires passwords intended to resist such attacks to be orders of magnitude more complex than those that are expected to resist only online attacks.
Which means that an attacker now knows that moving "only numeric" to the beginning of their attack sequence may be a viable strategy. Whereas if the rule did not specify, the attack would not be able to make assumptions about the character set.
On a few sites I've actually used old student ID #'s - easy to type and reasonably long, with the exception of one, all are 6+ characters.
Far too short.
Key material rotation seems to be a sensible practice in general.
(26+10)⁶ = 2,176,782,336
1,450 minutes a day
2,176,782,336 / (1,450 * 60) = ~25,000 years
Number of 6-character alphanumeric passwords: (2*26+10)**6 == 56800235584
Number of seconds in a year: 60*60*24*365 == 31536000
Number of years to enumerate all 6-character alphanumeric passwords at one password a second:
(this assumes that alphanumeric is [a-zA-Z0-9], which some might disagree with)Not meaningfully. Let's take my Hacker News password and we'll imagine you happen to know (somehow) exactly what the format is, so then you start guessing.
And we'll imagine you can make 1 billion login attempts per second, which in fact I'd guess will make dang pretty unhappy 'cos the servers won't like that.
And maybe you get to do this on a billion computers, and for a billion seconds, again I'm thinking somebody would notice and stop you, but let's just say...
At the end of all that you've still got orders of magnitude less chance of guessing my password, for this web site correctly than a random ticket buyer has of winning the jackpot in a typical state or national lottery game. Get a new hobby.
I think people struggle with the numbers involved. Even astronomical numbers are too small, because astronomical numbers involve practical things, like how quickly light travels and maths does not need to be practical.
"There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers." - Richard Feynman
If you're logging in from a library computer, you don't want the hassle of putting your privkey file on it and wiping it later. (Or connecting a USB drive, which may be a security hazard for the library)
If you lose your computer, you still remember your password, but your only copy of your privkey may be lost. Losing hard drives is common for non-power users, because they don't do regular backups, and they often don't know that you can trivially recover files from, e.g. a laptop with a broken screen that won't boot.
And computerized cell phones are actively trying to convince those non-power users that files don't even exist, to protect their profits.
Now, public key cryptography is indeed promising, but you see something rather more sophisticated to deliver privacy and security and that's what WebAuthn is.
I'm not clear on the password part (I'm assuming it was a typo).
But let's say you want to do it anyway. There is no need to memorize or type the entire key; a site-specific private/public keypair can be derived from a memorized master password and the domain name (for uniqueness) via a KDF. The site never needs to see the master password, so in the event of a breach all your other logins remain secure, and there are no key files to synchronize, just a single password for access to all your accounts.
You do need to trust that the PC you're using to log in is secure, though, since it has access to the master password; I'm not sure how you would get around that without involving some other trusted piece of hardware, and if you have that you could just use it to access the site instead.
I have no idea why this wasn't immediately huge. You see the login button, you tap it, your existing fingerprint reader or whatever verifies you are still you, whoever that is, and you're logged in, done. Much more secure than people's crappy passwords, yet much easier to use even than the crappy passwords.
When you ask people to remember too many passwords, they start writing them down and/or forgetting them, which leads to other problems.
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.
Writing passwords down isn't the worst thing. If you can't convince someone to use a password manager like 1Password, getting them to use a physical notebook of unique and strong passwords is actually the next best thing, because (combined with 2FA) it protects them against the most relevant threat models for most people (phishing and password stuffing).
The only reason it's even tolerable risk to walk around out in the wide random world with a debit or credit card on your person all day every day, is because somewhere else you have the means to disable it and declare it lost.
This is like storing the keys to your car conveniently right on your car.
At home maybe, but in other environments this can be pretty bad.
We either need password managers or we need to do away with passwords entirely.
A good analogy for banks risk mitigation is like putting up a guard rail in front of a cliff. It's up to the user how high the rail gets set. Like daily limits, notifications, initial passwords, 2fa etc.
For the most part, banks and brokers want to reduce the friction of events.
Nobody complained. I think it's a better solution than making the user come up with their own strong password with annoying special character rules when you can just generate one for them.
The interesting challenge was making it work well with all password managers though which often have mind-numbingly dumb heuristics about what could possibly be a password field. It's worth a blog post.
You don't know and that your brokerage did not ask you - it can mean anything, they might have had a breach already but they kept it secret.
Idea about rotation of passwords is that you assume that your password 'was leaked/cracked' and you don't know about it and have no way knowing it.
That's really not the user's responsibility at that point. It's up to the service to store passwords securely (i.e., use proper password hashing functions) and monitor login behavior to throw up extra challenges if things look suspicious.
Password rotation is a high-cost measure placed on the user that has little (even negative) benefit, especially when there are more effective alternatives the service is better-positioned to implement. Users cannot twist themselves into knots to make up for shitty service-side design decisions.
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.
[1] https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-0... Approachable summary at https://www.bastionzero.com/blog/i-read-the-federal-governme...
If you're generating your passwords randomly (using a password manager) it actually reduces security because it reduces the set of acceptable passwords.
Of course modern dictionary algorithms will still look for characters that are commonly used as substitutes for letters ($ = s, # = h, ! = 1 etc.) so really you just want your password to be random, long and unique.
P@55w0rd!
Is an awful password, yet meets many security policies
P@ssword2, P@ssword3, P@ssword4 etc
Also meet them, and rotate just fine.
Meanwhile
dadbffc67f798e8e0b7441fb995aeabe
Is perfectly fine, but often is not allowed
Nor is "correct horse battery staple". For wanting symbols, so many password systems really hate spaces.
I don't think anyone, even the original responder, views it as an actual password we should all use.
Don't worry, the first 10 letters are randomly generated a-z or a-z0-9.
Does actually. I still require some of the password "rotation" schemes folks would use when we were forced to change them monthly (not a typo, sadly):
1qaz2wsx -> 2wsx3edc -> 3edc4rfv...
Pass1word -> Pass2word -> Pass3word...
Upper case, lower case, digit, special character, does not match any previous password, changeable monthly without having to write it down…
Yeah, that's because those stances are not based in fact, but repeated bad ideas left over from the 70s and 80s.
The U.S. Fed Gov has been implementing MFA with smart cards since 2001. While there are pockets of ineptitude and resistance, the vast majority of government employees and contractors use a hard token second factor.
Security is a property of a system, so analyzing a particular password policy outside of the given context (mandatory hard token MFA) is nonsense.
Except other national bodies like NCSC [1], and long-standing academic research e.g. [2, 3], that is!
1. https://www.ncsc.gov.uk/collection/passwords/updating-your-a...
2. https://dl.acm.org/doi/abs/10.1145/1866307.1866328
3. https://link.springer.com/article/10.1007/s10623-015-0071-9
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.
For my own personal use, I just use a password manager + randomly generated passwords, but it seems corporations are so damn slow to pick up on these obviously beneficial things that they choose clearly antiquated standards instead.
3password
4password
...
>=]
Anything below 5 in distance gets rejected, try again, please.
While you get to change password you make 2 boxes with current and new of course and do your comparisons on it, just to explain you still keep passwords hashed.
password02february
password03march
...
These can go undetected. Imagine
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
A lot of time can pass between these steps. Changing your password is a mitigation against this scenario.
If you steal the WebAuthn database from my toy implementation, now, or tomorrow or ten years in the past, it makes no difference because it doesn't have any secrets in it, so, you don't learn anything useful. "Man, if I was this web site, which I'm not, now I could validate that the authentication was successful".
In such schemes the only thing similar to a "secret" is the Private Key, which exists only briefly temporarily inside my Security Key or other authenticator when it is doing its thing.
I highly recommend it for people that are more computer savvy. For the digital illiterates OnePass may be more suitable.
PasswordSafe was designed by Bruce Schneier.
I'm the person that you should thank for that, I believe.
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).
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.
It has take literally over a decade to relax the requirement for password rotation from 3mo to 1yr for employee accounts of companies that process CC payments, despite industry knowledge and formal studies saying that frequent password rotation was detrimental and useless.
Instead of defining the process, state the outcome you want and set penalties on failing to meet the outcome.
E.g. "don't have password leaks, or it will cost $1k per account paid directly to the account holder" (or your percent of gross, split among leaked accounts). Let companies implement those controls however they wish, as long as they are achieving the outcome and penalties are actually being applied.
I agree that failures need to have significant penalties, otherwise companies will decide that the penalty costs less than the prevention (which is true today) and minimize their investment in security.
the Hive infograpgh (amongst others) always comes to mind; 18 characters long, upper, lower, numerical, special. estimate time to brute force 438tn years.
That seems like a good way to ensure people don’t use stupid passwords: public embarrassment.
If you're worried a password will leak, how frequently should you rotate it to maintain security? e.g. Even rotating yearly still seems a chore if you do it for websites you don't frequently visit (such as sites you made 1 order from).
The "add YYMMDD" or whatever is a way of working around a policy which automatically enforces a more frequent rotation than you want.
Sure, it's technically possible to decipher the algorithm[0] I use to generate new passwords, but that's not what I'm protecting against. If someone is trying to attack a specific person, there are much more effective ways[1].
[0]: For example, if my password for HN is "1y2c3o4m5b!$", you could sit down and figure out my reddit password.
[1]: https://gizmodo.com/how-i-lost-my-50-000-twitter-username-15...
Assume the passwords for all of your users are public. Doesn't matter how it happened. How are your users protected?
The moment that people go down this road of thought everything gets a lot better.
1. How do you restore accounts that may have been taken over?
2. How do you detect logins that look like normal behavior vs those that don't?
3. Is a password alone enough to get them in?
If you address those 3 things everything gets A LOT easier for you and your users.
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.
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.
Leaking a password on your side is an unknown unknown, so password rotation is not a bad practice on its own for a security conscious person: It limits a leak in time.
Mandatory password rotation is a whole different kettle of fish, as it pushes users to lower password quality. Infosec policy was required to balance 2 conflicting needs, and the past has thougt us we balanced wrong.
Even if you rotated your password frequently, there would still be a large window of compromise. Password rotation only helps with very strange attack scenarios, and passwords themselves aren't really good enough for anything where security actually matters.
I would personally push away from passwords on the whole at this point. SSO is probably more secure for most users. Plenty of websites only support username+password auth, and given how bad most passwords are... I might even go so far as to suggest that username+TOTP is instantly more secure than that, especially with proper rate limiting as you should have anyways. (Yes, I know TOTP is "supposed" to only be a second factor.)
WebAuthn takes this to the next level and promises a future where you can use a strong single factor to log in, without any opportunity for phishing or credential compromise... but most implementations I've seen still require a fallback password mechanism. There are understandable reasons for this right now, but it is unfortunate.
There original threat model for forced password rotation was supposedly based on hash cracking time. This is a stupid threat model; the guy from NIST who wrote it back in the 80s admitted it was based on no research but was added arbitrarily because it sounded good at the time.
I'd say no... some compromises are "2 step"... Ie. someone accidentally was logging the passwords in plaintext for a few months to some logs system (compromise 1)... and then years later some attacker breaks into the logs system (compromise 2).
Or you accidentally typed a password into a terminal and it got stored in your .bash_history... and then months later you accidentally make your dotfiles github repo public, including your .bash_history containing your password...
Also, some thieves may compromise your account but not do much evil with it (and remain undetected). And then many months later they sell your account to someone else who does do evil with it.
But updating a password is itself an attack surface. More so than merely using it to log in.
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.
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.
Basically updating a password is a riskier action than the normal daily use of the same password.
And that alone is it's own even stronger argument for avoiding doing it unnecessarily.
She only knew because I'm on the recovery password list and as soon I received the email from Google asked her to confirm.
At every company I've ever worked that required password rotation, everyone just incremented a digit, usually at the end.
I also hate the completely arbitrary rules on length (I mean, why do some sites have a maximum 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.
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.
[1]: https://xkcd.com/936/
This assumes you'll know if passwords were exposed in a breach. Some breaches go undetected.
If you use unique passwords for everything and a leak goes undetected, the damage is contained to just that one site/service.
cherry picking quotes to nitpick is only effective if you address the full quote rather than cherry picking a point of a cherry picked quote
- The password is weak
- It is ever reused
- Anyone else has access to it
- You use it on a device you don't control
- You use it on a device which might be running malware and can intercept it
- It was stored insecurely
While sharing passwords is never a good idea, sometimes it is necessary. For example, I am the treasurer of a non-profit organization, an elected position that rotates every two years. We have a savings account at a credit union that for a variety of reasons requires online access by multiple individuals who change over time. The only way to keep this even a little secure over time is to require a password change every time someone drops off the authorized access list.
There could also be software licensing issues that lead to multiple users sharing a login for software, same thing applies.