I believe this has been Microsoft's guidance as far back as 2016, with the caveat of using Azure AD risk analysis /MFA.[1]
>Password expiration policies do more harm than good, because these policies drive users to very
predictable passwords composed of sequential words and numbers which are closely related to each
other (that is, the next password can be predicted based on the previous password). Password change
offers no containment benefits cyber criminals almost always use credentials as soon as they
compromise them.
>Mandated password changes are a long-standing security practice, but current research strongly
indicates that password expiration has a negative effect. Experiments have shown that users do not
choose a new independent password; rather, they choose an update of the old one. There is evidence to
suggest that users who are required to change their passwords frequently select weaker passwords to
begin with and then change them in predictable ways that attackers can guess easily.
>One study at the University of North Carolina found that 17% of new passwords could be guessed given
the old one in at most 5 tries, and almost 50% in a few seconds of un-throttled guessing. Furthermore,
cyber criminals generally exploit stolen passwords immediately.
> These policies drive users to very predictable passwords
I used to do a lot of contract work for the Clarke County School District in Athens, GA. For "security" reasons they weren't able to create domain accounts for people who weren't full time employees, so I'd often have to track down the IT manager to gain access to servers I was working on.
He eventually got sick of having to drop what he was doing a dozen times a day, so one day he just gave me his password: a dictionary word followed by the number 23. Eventually the password failed, and he gave me his new password: that same dictionary word followed by a 24.
Fast forward a few years and I'm back installing some updates, and before I get to work he hands me a slip of paper, on which he had written Dictionaryword29.
> a dictionary word followed by the number 23. Eventually the password failed, and he gave me his new password: that same dictionary word followed by a 24.
In a similar vein, over the past few years whenever I've got in a discussion with IT people who defend mandatory password change policies, I ask them to give me the last password they were using before changing it. No one has ever taken me up on that.
I'm relentlessly difficult. So at the last job where I had mandatory password change policies I could have told you my previous passwords† and they were all just random gibberish. I think I had to change them every 45 days, and I had a total of six passwords, although only three of them had to be changed every 45 days.
However, I would also not defend mandatory password change policies, so you would never end up asking me :D
† I can't tell you now because the day after I ceased working for them I sent the nice leather-bound book I write passwords down in to my Product Owner, so that the answer to all subsequent "Do you happen to remember the password for...?" questions would be "Either it's in the book which you have or No". To be fair he only called me and asked that question once, which is why he was my favourite Product Owner, "capacity to learn from experience: 10/10".
Writing passwords down on paper is literally the primary reason password rotation isn't recommended anymore.
If something got a look inside your book, everything is compromised. At least by changing to another random gibberish password, an attacker would not get back in (in contrast to someone that increments a number, for example), but how much damage can something do in that time before you notice? How long do you think it takes a skilled attacker to install a backdoor (the answer is definitely less than 44 days)?
This is the second major problem with password rotation: it is false security. If credentials are compromised, immediately change them: don't wait 45 or 90 days.
If they're not compromised, changing them is basically pointless, because humans are going to human and either have an incrementing number, predictable pattern, or actual complex, random, unrelated passwords ... that they then write down.
Writing passwords down on paper and leaving that paper in an insecure area isn't.
Your little address book full of passwords is the same as a password manager, and for a lot of people it's easier for them to manage the security of a booklet than it is to handle a password manager properly. And for those people, it's definitely worth using a book for the sake reasons we say using a password manager is a good idea
I do actually use a password manager (zx2c4's pass) to manage my own passwords. But my mother has a book I purchased for her as an Xmas gift one year, for exactly the reason you described, I am confident she understands the security properties of a book, (e.g. a stranger left alone in a room with the book can read it) whereas I have my doubts with a password manager.
I used a book for passwords issued by that employer because at that time they lacked any in-house password manager and I foresaw from the outset that I would want to be able to hand them "my passwords" in the limited context of that employment as distinct from stuff like my personal Wikipedia account, my Google account and so on.
That's correct, if bad guys broke into my home and accessed the book it would have been game over.
Personally I would be much more concerned about other things - my stuff is there, not to mention often myself - but I'm sure that a vast faceless corporation would be primarily concerned with the potential for these hypothetical bad guys to learn and maybe disseminate secret passwords.
How often do you think that actually happens? It's a bit... high risk for opportunistic "cyber criminals" don't you think? Figure out where key employees live, then break in and... look for passwords they've written down and then presumably use them quickly before they're invalidated.
If I have a paper book of passwords at a desk in an open office environment, sure, that’s bad. If I have a paper book of passwords in a locked safe in a house, and there is perhaps a large German Shepard and multiple able-bodied adults living in that house, I’d say my password book is relatively secure.
Besides, actually remembering your passwords is a security flaw, too. Memorable passwords are naturally less random, and if the password is in my mental memory, an attacker can compromise my password by smashing me over the kneecap with a heavy wrench until I tell them. If I don’t even know my password, that’s probably bad news for my kneecaps but slightly more secure overall.
When my house got burgled, they didn't even bother taking my MacBook, let alone any real books. Your average burglar is looking for cash and items that can be quickly pawned, not corporate secrets.
If someone did break into my house as an act of espionage (corporate or nation state), I'd be worried about much more than just my password security.
You can improve security of the booklet with secret splitting: type the strong part from the booklet then keep typing "hunter2" from memory. The (strong) booklet part protects from machines, the (weak) remembered part protects from humans. Weak passwords are ineffective only against machines, they are still effective against humans.
I suppose that typing "****" on the end of your passwords would work. Bit annoying to type out 7 asterisks every time though, maybe a word would be better?
Most of the people I know use some kind password they can derive if they forget it. Like their password for Company A will be the city the company was founded, city the founder was born, and the month/day it was founded. The ones who have to change it because of policy pick something iterative, like the first line of a song, then the second, etc.
Most of the people you know are well outside the normal then.
In my experience the average password consists of 1-3 words with some meaning to the user, sometimes either in 1337speak or followed by numbers/symbols if the password policy requires them.
I'm with you on this. I know very few people who generate passwords like that and most people I know use some simple "special word with special number" pattern. Often it's kids names, a random word they picked as a password years ago and have been reusing, and some part of their pin number.
In the past, I used a grid of random characters (a tabula recta) that I keep in my wallet, plus an algorithm for pulling passwords out of it. This system broke down when I was forced to change passwords on various sites.
With passwords that simple, it's crackable almost instantaneously without any preknowledge of the password format. That, coupled with the fact that systems get randomly attacked all the time, I doubt it's really that big of a deal.
Attackers don't need hints on passwords, they don't need hints on targets. They just target everyone, and try all easy passwords.
It depends on the context, if I have a hash it’s trivial to crack dictionaryword29, if I’m brute forcing a VPN/RDP endpoint, generally fail2ban are hard enough to block mass attempts (an AD default, iirc), the latter is usually solved by phishing which has the added benefit of MFA capture also.
Yes... there are lists that are generally used for common variants of passphrases and can generally crack a simple passphrase like ggp in less than a day easily, faster or slower depending on hardware in use, concurrency and order.
4-5 dictionary words with proper sentence structure is a lot safer for the most part. Random safer still, but much harder to remember... my current password for work in a sentence with 24 characters. spaces, capitals and punctuation. Other than my OS and password manager, I really don't remember any other passwords I use, and the majority are random generated at this point.
I also use a wildcard mail forwarder, so most new sites I've used in the past year or two are all unique emails as well.
If you're relying on all former colleagues not inadvertently (or otherwise) giving away details that may (slightly aid in the) comprise (of) your systems...
There was a talk I saw some years ago of someone that analyzed enterprise passwords and the most common pattern they found was:
Dictionary word with first letter uppercase, followed by two-digit number, followed by exclamation mark. With the overall length exactly being the minimum length of the policy.
My first password is always secure. The second one less so, but by the third time you make me change my password it turns into easily predictable dictionary words.
So at least three reputable sources recommend not changing passwords periodically. Maybe that can persuade my employer though i doubt it.
One aspect though is that some people tend to use the same password in multiple places and with passwords ending up in https://haveibeenpwned.com, you might argue for periodic password changes.
That's correct. PCI DSS section 8.2.4(a) requires that passwords are changed at least every 90 days.
Other requirements from the same section: retain old passwords to disallow dupes for at least 5 cycles, passwords must be minimum 7 chars, and contain both alpha and numeric.
You might be able to justify non-compliance with a compensating control, but I've never heard of anyone who tried it.
Note that this only applies to employees who are in PCI scope. Most internal staff are not, and should not be!
Similar policies are common for all users though. They pre-date PCI (which is how they became part of PCI DSS) and now PCI's retention of these policies justifies continued use elsewhere. The tail wags the dog.
> You might be able to justify non-compliance with a compensating control, but I've never heard of anyone who tried it.
I just did similarly within a SOC2 audit. I sent the auditors a list of 50+ articles and references i've been maintaining for years saying that password changing is a bad idea (this article is on the list) from many different sources. I never heard back and the item was marked approved by them.
I've actually known people who, when required to change their password, would change it 5 times in a row, then back to the original password in order to keep using it.
Yeah, I've tried that. First day in my new job. “Here's your PC. Your user name is [some initials] and your password is abcd1234". I sign in and immediately proceed to change my password to something that doesn't suck. I keep getting an error message about my new password not meeting the complexity requirements. Super confusing... I give up.
Next day: I can now change my password.
Turns out that I couldn't change my password the first day because it had already been changed to abcd1234 that day. I was not impressed.
It is internal joke, you 'forgot' your password, so you get something like 'Spring2021' from IT as password reset. Now you pick a target account, trigger account lockout. Most of the time, the target is confused and gets a combo, account unlock and password reset. Now the IT guy who does password reset ... uses seasonal passwords which of course can't be changed for 24 hours.
Oh this is clever, I’ll use that next password rotation so that my password doesn’t change in effect. We must change every 60 days where iWork, and it doesn’t work well so some systems still use the previous password, some still use 3 passwords ago, etc. It’s random though, you never know in which systems the password change will take and in which it won’t)
I went to a college with that problem. After your mandatory password change, any device autoconnecting to wifi would trigger a lockout. Since the same password was also use to log into network computers, there was no way to visit the webapp to unlock your account.
Unless you had data on your smartphone or had a friend who was logged in, you were SoL.
Slightly more tech-savvy users will just use a password manager... called "passwords.txt" file saved on the desktop.
Won't work for the Windows password, but with more and more corporations outsourcing their tools to the cloud, system account password is rapidly becoming the least important one (like it already is for most people's personal devices).
Absolutely. Worked in SAP (the variant used by last place anyway). Don't think it was as many as five, three maybe, or change it and change it back even.
This is a good idea, if the passwords are the ones people change *from* (i.e. once you change your password, it gets into that list). This way nobody can use the password anymore (with the idea that it is a weak now, for any reason).
This is selfish, though. If that database of passwords leaks, they are prime candidates to test on *other* sites.
If you encrypt the prior passwords using a key derived from the current password, you're enabling this sort of check on password change without really sacrificing security, don't you?
> If you encrypt the prior passwords using a key derived from the current password,
How can you do that with a prior password if you didn’t store it as plaintext when it was current? You can’t encrypt something you don’t have. Unless you are encrypting the old hash, not the password.
Yeah that was the idea. I guess a lot of apps don't actually do that and just email you password reset links, in which case you can't actually recover the old password. :<
The excellent (or horrible, depending on which end you're on) pam_pwquality[1] module for Linux allows rather fine-grained enforcement of how much a new password must differ from the old password.
PCI is just so asinine it made me want to poke my eyeballs out when I had to go through it (Level 1 Service provider). In some situations it actually prevents you from being more secure.
One of the reasons why I want the Credit card cartels to die.
well I've known more clever users, guess what you need to do if your password needs to change every 90 days, but you need to have a different password for at least 5 cycles?
This is how I used to do it. Just slap the year and Q on the end whenever it wanted me to change it. End of the quarter gets a bit tricky if things don't line up but it's mostly muscle memory by then
This is why when I built our systems, I did most of them using a combination of public/private keys and TOTP 2fa. Also severely isolating those systems so that the list of people who need access is as small as possible.
It's orders of magnitude less of a pain in the ass than password cycling.
I've worked at places that would disallow re-use for the last 30 passwords. When you're forced to change every 3 months you're looking at a company maintaining a password history for over 7 years.
How is that managed? Are they hashed or stored in the clear? If they were hashed, then they would have to know which algo to use for a password at a point in time otherwise they would lose that data whenever they switched the hashing mechanism.
And when that data inevitably leaks, attackers have a nice table of passwords and metadata that will easily help them out in other places.
A solved problem with public key crypto, where you are in full control of the secret and can take your own steps to protect that.
I believe Active Directory just stores the hash like it does for your current password. Yep, if you crack the domain controller or grab a copy of the backups and get those hashes then all the bets are off. You also get their current passwords because they're there as well, so its not like having the old ones makes anything worse. And of course, if you do have admin privs on the domain controller, you can do a lot better and easier things than bothering with those hashes anyway.
This is why the modern approach is something you know (password, PIN) plus something you have or are given (time code, texted code, face, fingerprint) for authentication. For environments with MFA, regular password changes seem like a solution that's no longer needed. Ours is a long password changed once a year and I imagine the mandatory change will be phased out eventually.
The logical assumption is that PCI does not consider satisfaction of 8.3 to be a compensating control for the requirements in 8.2.4 -- however I've never heard of anyone who made the attempt.
...
PCI is a weird mix of requirements, evaluations, and compensations. The final authority is the PCI org themselves (i.e. the card networks), but the eval is performed by PCI-approved third parties, for report to your business partners. Requirements are extensive but not always definitive. Compensations are subjective, at best. Enforcement is sketchy but can be devastating.
The usual approach is to comply, comply, comply, and accept that some of it is policy theater, but it's rarely bad policy.
Password rotation is bad policy, but ironically it's mitigated by MFA!
I’ve had a number of Level 1 merchants/service providers ditch PCI password complexity/rotation rules, and I’ve always managed to get it accepted by QSAs.
The compensating control is to implement the full NIST recommendation (like enforcing an extra long password length, monitoring for compromised passwords, having a documented passphrase policy, etc...), and in your compensating control worksheet describe how those practices go above and beyond the DSS requirements. That bits quite simple, because there’s plenty of authoritative resources you can reference to justify that position.
The harder part is coming up with a justification for why you need to implement that compensating control. Because a compensating control can only be implemented to address a legitimate business/technical constraint. But that bit really just takes a little creativity.
Those are the defaults for the little authentication management app I wrote a year and a half ago... Defaults are NIST guidelines, with options to implement "typical" adjustments, like rotation requirements. Default min-length is 12 iirc, and does a check against zxcvbn and the haveibeenpwned list. zxcvbn is displayed/advisory by default, can be set to required and the pwned list is enfoced, but can be toggled off.
Also, use of the term "passphrase" instead of "password" and recommending a short sentence with multiple words, casing, spacing and punctuation.
It wouldn't surprise me if this were a regulation requirement, since most very large companies I've worked with all have pretty much identical password expiration policies.
Change travels very slowly - some years ago NIST and everybody else's recommendations used to require password rotation, so lots of policies and habits of policy writers/enforcers and educational materials still echo the old recommendations.
This requirement can come from lots of places. I remember at the last place I worked, we had to get audited for SOC2 compliance and password expiry was part of the requirement. I imagine these things lag behind the recommended security guidelines by quite a few years.
SOC 2 is defined by the American Institute of Certified Public Accountants. Having computer security defined by accountants seems crazy, but is in the style of the bureaucratic mess of modern enterprise.
Don't recall for SOC2 specifically, but a lot of the time, "best practices" suggestions and the requirements weren't the same, and people codified the suggestions internally, or the reviewers/auditors would.
One thing to remember that large companies love things which they can point to if something goes wrong. PCI isn't regulation but it's widespread because the credit card companies require it. Depending on the industry you might also find CIS pretty common (https://www.cisecurity.org/) and the U.S. federal government space will mention STIG (https://public.cyber.mil/stigs/).
These are built into common assessment tools so you'll get identical policies down to things like byte-for-byte identical PAM module config because most places just licensed one of these tools and demanded everyone use it.
I've also seen it written into business contracts with clients. Which makes it almost impossible to change, because doing so would require both sides to agree to pay for an expensive (and irksome) exchange between their respective legal teams.
Regulation is usually pretty light on specific technical measures, it says something vague like "you must follow best practices" and then there's industry consensus / rumors about what those are.
For odd historical reasons HIPAA is passive-aggressively prescriptive through the definition of secured PHI in guidance issued under the HITECH act, whereas the basic Privacy and Security Rules are less so.
> It’s more about defining what PHI is, and what the consequences are for mishandling it.
Well, the Administrative Simplification part of HIPAA (which is far from the whole thing, and which the Privacy and Security pieces are in turn smaller components of) are really more about standardizing and encouraging use of health IT in multiparty interactions in healthcare. The Privacy and Security aspects were included largely to mitigate public fear of shared, common-format digital transactions and records being a privacy risk.
Is this similar to Enigma decoding - whereby the 'encoding' key was reasonably predictable and not random due to new keys being required to be generated regularly?
This been Google's guidance for even longer time, if not forever. I worked at Google for a year and was very surprised about that. Before that I had to find ways to memorize the new password every 60-90 days.
Unfortunately Microsoft was inconsistent with this advice. They published that article in 2016, however in 2018 I logged this issue regarding their published best practices:
>cyber criminals almost always use credentials as soon as they compromise them.
There's still the problem of breaches in unrelated services, which must be considered as part of the attack surface when users can just use a single password anywhere. This to me seems like the most obvious benefit of expiring passwords.
For those who may not know, password cracking/brute-force tools have all of this logic and more besides.
Whatever human-rememberable algorithm people are using to rotate passwords, if an attacker knows a password they used
at any point previously they'll get the new one quickly.
Just have to hope that mypassword03 on the work account is not in sync with mypassword03 on the facebook account then. And that no one either automatically, or as part of a targeted attack, notices the 03 and tries 04 (and etc).
Nobody remembers real passwords so they come up with frameworks to have a pattern that meets policy.
I did a consulting engagement a few years ago where we cracked 60% of passwords in a 40k user directory in under 3 hours, on a laptop. Every password met NIST complexity requirements of the time.
Neither password is secure once it leaks, though. That’s the problem when people pick a secure password but then use it everywhere. This is why password managers are mandatory for secure passwords.
iOS has the right approach: they suggest random passwords in Safari and explain why, then save them in a local hardware-encrypted store with biometric quick unlock. Downside of course is they also sync to Mac and don’t have the same usability in other contexts. Windows support was recently added, but is only as secure as the TPM option and firmware of your BIOS/CPU chips and given encryption requires Pro, it’s possible some security features also require Windows 10 Pro. I’m also not sure how iCloud for Windows communicates with Chrome or if that’s been documented somewhere. https://support.apple.com/en-ca/guide/icloud/mmfeee20145e/ic...
A permanent solution is to skip the password and just use biometrics and machine identity, such as with FIDO2. Obviously not required in every scenario, but much more secure than a re-used password, even one that hasn’t yet leaked, because it might still (be leaked due to re-use, that is). Add to that tracking of which machines and locations a user logs in to for flagging suspicious “I can’t access my account,” requests etc. Encourage users to log in from more than one device if they can to help regain access automatically if a device is lost or reformatted…
Sign in with Apple, required by Apple for all apps with social logins, will only prompt you for a password when you don't have Face ID, Touch ID or a PIN set on your device, according to https://support.apple.com/en-ca/HT211687
So that's effectively the same thing as if the site only used FIDO2 - because that's the same technology Apple uses within Safari and other web browsers to implement Sign in with Apple.
Every once in awhile Google Chrome will prompt me to sign in with a password, skipping the 2FA check, just to validate my identity. It's kind of pointless, really. If they can't trust my device to be secure, why are they asking me to enter a password on my device? That just weakens my account's security if they legitimately couldn't trust my device... Better to have my device validate its ID and my ID via Windows Hello or the same FIDO2-style biometrics and call it a day.
Biometrics are simply the equivalent of tapping a FIDO2 button. They don’t increase security as much as they are a signal to authorize that prevents less dedicated users from opening the device. The device, not the biometrics, provides the security guarantee to replace a password.
You can opt to replace any biometrics with a device-specific password that is more secure than other passwords because it never leaves the device or even an additional two-factor key, at the option of the device maker.
For example, you can use a separate FIDO2 key within Windows Hello for enterprise use cases against Azure AD instead of using biometrics to sign in to your computer.
Folks can choose what level of security they are comfortable with. For me, personally, and everyone I know, passwords are much easier to steal and reuse because they leak regularly, can be tested multiple times without consequence, and so on.
To be clear, I’m saying password managers are awesome but device-based security is more awesome. Add a local password to your device based security is more awesome still, but then so is having a friend approve your request or other additional layers of security. Biometrics are the new PIN code “minimum” not the best we can do but better than sharing one string of text with the rest of the internet and assuming it will never leak.
Note that the risk model is roughly identical if a device is lost. Just as with a compromised password, you would have to visit websites using the device directly and revoke its access. This is made simpler if you combine FIDO2 with OAuth2 because then you only need to de-enrol the device from Microsoft or Apple. OAuth2 provides an additional layer of protection because it can tell you when your device is used, and can add additional security factors such as notifying you when a login occurs that not every site might build. OAuth2 does this by replacing passwords with timed tokens depending on how it’s configured, so at minimum new tokens are logged.
The same applies to the use of short-lived credentials in AWS or other cloud providers vs using permanent secret tokens. When using permanent secret tokens, like passwords, these are often very hard to rotate without consequences because you do so very rarely. They are also subject to reuse on different machines. By comparison, a short-lived token can use machine identity on a cloud server to add an additional layer of protection, and depending on the authorization system could validate a local device, use of a second FIDO2 or biometric device, validate the server requesting delegate permissions on your behalf, and validate the duration and scope of data being accessed, all at the same time.
In highly sensitive scenarios, one could even use asymmetric encryption stored on devices to ensure that any intermediate or delegate servers cannot decrypt API responses, only the recipient of the data. Of course, you need a model to trust your client app, but App Stores notarization and containerization go a long way to making it easier to wipe and redeploy secure machines frequently, such as with every system update, optionally leaving user data alone.
There's a difference. If your FIDO2 key has biometrics (such as touch ID) then it's still a FIDO2 key. It means if it gets compromised (lost or stolen, for example) then you need both the device and the biometrics to gain access.
If your fingerprints are lifted/leaked from a glass, for example, then published, your attackers also still need physical access to the device you use biometric security against.
If that's public, such as your house front door, I agree, you've a problem. If that's your cellphone, then you have to ensure you don't leave your phone unsupervised.
The same is frankly true of other exploits that can be done in-person, such as USB attacks or PIN code screen bypass, and so on. Once you have physical access to a device, you can authenticate via many means, not just biometrics.
Bitcoin miners are doing around 170 quintillion hashes per second, so if all of those resources were put toward cracking these passwords, in theory it should take around 20 billion years for the longer one [1], or about 38 milliseconds for the shorter one [2].
Well OK but not all passwords are hex numbers! Given that testing a few simple classes the length of the shorter one takes about a second or two then that seems worthwhile.
It's been a while since I fired up John the Ripper but it has low hanging fruit modes built in.
So even if you are using quite long simple alphanum strings of gibberish then seriously consider adding one or more character class into the mix eg capitals and easy to identify special chars like $£% etc.
To really go for gold why not mix entire scripts eg the usual en_* alphabet and say Bulgarian Cyrillic. Gasp as your keyboard mapper explodes! Alternatively, look into MFA.
Yeah -- I assumed that a random hex password was chosen, and that the attacker does a brute force hex search (e.g. JtR with Incremental:LowerNum). Granted, in practice the attacker usually doesn't know the exact format, so they might waste additional time searching other formats.
I agree about incorporating other characters. As long as it's not "Dictionaryword1!" :) https://youtu.be/aHaBH4LqGsI
Maybe Bitcoin needs a “proof of proof of work” now. If some entity wanted to brute force an attack on the worlds passwords, the increased electricity and heat would be detectable. But they could hide the activity it inside Bitcoin mining. A proof would be needed.
Most passwords will come from a set of around 100 characters (52 letters, 10 numbers, about 35 symbols on my keyboard). An 8 character password would be 10^17 options.
I've worked on a lot of important, widely-used software and 6+ alphanumeric has always been copacetic. While more esoteric requirements a major pain point.
> Experiments have shown that users do not choose a new independent password; rather, they choose an update of the old one.
Such experiments clearly do not introduce the use of password managers which promote the generation of long passwords with high entropy.
Specifically in the case of master login passwords, where the usage of a password manager isn't feasible (like Active Directory and Windows logins), this may be the case. And it still requires that the domain forbid PIN/biometric logins and thus result in people complaining about entering long passwords with entropy each time.
Exactly. My university requires a yearly password update. I have to manually enter my password to log into computers, print release stations, a billion domains that just use an LDAP connector instead of our Shibboleth page, servers after home directory wipes, etc.
My password needs to be something I can quickly type, so I just use the same one (a strong, multiple-word passphrase) and add its validity period to the end.
This actually makes hitting arbitrary password requirements easy too; make one word capitalized (or one lowercased), separate each with an allowed symbol, and the validity period is numeric so it passes just about every security check while being easy to type and remember.
Indeed, my work login password, with regular rotation requirements, has been dropping entropy by a few bits each time it comes up for renewal. I work to make my work passwords as different as I can, but that password doesn't get used enough for me to trivially remember it, and it can't be offloaded to a password manager easily.
I'm on a Mac and couldn't be arsed setting it up properly ;) It's fairly easy to put a static OTP on two keys incase I lose one also instead of trying to register two with the OS.
Also I can use it for various other things (like password manager secret etc) which don't support yubis out of the box.
I use 1password for everything, but I need to type my professional Windows password every time I log in, I'm not copying a password from my phone every time I come back from the bathroom.
I used my PW generated password on a site earlier, the site refused to accept it. 2^102 bit aren't enough (18 from 52 random upper/lower characters) aren't accepted, but P@55word was fine.
Agreed - there's so much I find frustrating about how companies manage passwords in addition to mandatory changing.
- Maximum length requirements (often secret until you try to put a password in)
- Requiring some symbols, but not others
- Silent truncation of the the password without telling you
- Failure because the password is too long, but the error says something else (like missing symbol)
This isn't just small unknown companies either. If you use a password longer than 32chars in Zoom when creating your account it just truncates the remaining without telling you. Login works on the websites, but if you try to login via the client it fails. If I manually backspace to 32chars it works. I tried to tell it to their US Twitter support and they just kept sending me a password reset link so I gave up (they're a bad company anyway [0]). Tmobile's website used to do the same thing, except worse because it would truncate on creation but not on validation.
How is this not standardized in some sane way?
An old credit union I was part of in NY (SEFCU) mandated passwords with exactly 6 characters. When I complained about this I was told it was secure because they forced one of the characters to be a symbol.
> Silent truncation of the the password without telling you
Bonus points for truncating the password differently in the login form and the password change form. Now you can't login anymore!
> Failure because the password is too long, but the error says something else (like missing symbol)
A few years ago the local City government in Paris put out some new app to pay for parking. You'd have to create an account and give them your credit card[0]. When I say they had some ridiculous maximum password length, something like 8 characters, I decided that I could actually take the five minutes to pay in person.
I haven't tried the app ever since, so no idea if this crazy limitation is still in effect.
---
[0] There was no option to give the credit card on each payment, they had to save it on file. Of course, they weren't aware that local banks were rolling out credit cards with changing verification codes, so some cards would've had to be re-entered anyway...
> Bonus points for truncating the password differently in the login form and the password change form. Now you can't login anymore!
Yes, when I setup my first password manager one of my banks said "max length 32" so I updated to a 32-character password. Then, when I next went to login, I found the login form had an off-by-one error and Javascript would truncate the password down to 31 characters.
I was lucky and knew just enough to be able to use the console to patch the Javascript on the fly. I complained to them and they said they'd look into it; a month later I went down to a 30-character password, to stay far away from any further off-by-one issues.
A big EU bank that I have my account (and an online account) with, cannot change customers OTP mobile phone number if they no longer have access to the old number (they require to send an OTP when number is being changed). The reason I know this is after several visits and calls over many months, all with a lot of effort put in. I am assuming they have zero CRUD that doesn't send OTP to the old number. A bank with billions should know better.
A bank with billions should have a manual process that may involve checking your identity in 20 different ways and maybe even pre-registering your whereabouts with the police, but ultimately resulting in giving you access to your account back.
I'm guessing it might take sending them a strongly-worded legal letter to make further progress.
But then it's in a single-sign-on system with some other services... Where that same maximum length is also the minimum length for at least one sub-system.
(I mean, hey, that's if you're lucky -- otherwise System A maximum allowed PW length is less than System B minimum required PW length.)
Schwab used to do the "silently truncate to 8 chars" fail, but they _also_ silently changed all chars to upper/lower so the password was case insensitive.
Still can't believe they were allowed to have such a bad and secret password policy for so long.
This is the second post in this thread where people for some reason expect banks to be better than others at tech.
I've worked at a bank, in software.
They are significantly worse at tech than other industries. They're propped up by usury, overdraft fees, slow, antiquated systems. Why does it take 3 business days to get a refund? The information moves in milliseconds today, yet it still takes 3 business days to get your money back.
> people ... expect banks to be better than others at tech.
Banks hold people's life savings among other things and thus, I would think, should absolutely be putting the best security to practice. Both physical (like safes and so forth) and technical.
I disagree. the 3 day delay is not because they want to put best security practice. If that's the case how does apps like Zelle transfers money instantaneously? I know in India, bank transfers are instantaneous and the receiver gets notified instantaneously. Some merchants even put their account number so people can transfer money to purchase goods.
Reducing the key space makes brute forcing easier. Nobody should accept such outdated password policies rooted in 50 year old practices that can't be safely used in a world with external threats.
I think I'm more worried about the lack of complexity than the guessability. It removes a huge amount of potential variance in any sort of brute force attempt.
Online brute force basically doesn't happen and can be managed by sane traffic filtering.
It does make passwords weaker. But 26^8 is still 200B. People aren't making 100B login attempts to break your case-insensitive alphabet-only eight character password.
Sure, brute force doesn't online typically, but isn't the reason we have most password requirements generally for the scenario where someone gains offline access to password hashes?
You really don't want to rely on a breach being just the password hashes and nothing else. In the case where the adversary was able to do literally nothing other than exfil the hashes, a stronger password will help you. But is this actually a common threat model?
And if you have SMS-2FA enabled, an adversary with your password needs to sim-swap you anyway, which is doable but scales very badly.
FB does case-inversion of the password. If at first the password hashes don't match, it inverts the case (not all upper or all lower, but passWORD <-> PASSword) to solve if the capslock is on or not.
They should do the CAPSLOCK variant (ie, passWORD -> PASSWORD). Why would inversion even make sense? If I type passWORD with all caps, and shift the last 4, it does PASSWORD, not inverted.
If I type passWORD with capslock on, I get PASSword when I apply the identical shift pattern (I literally just did this in this box!). This way if I have capslock on when typing my password, but I got the shift pattern the same, it'll still go but it doesn't wipe out my case changing patterns in terms of password security.
I'm pretty sure this behavior of capslock is pretty common across most platforms, I can't think of a platform it didn't do this on. It worked just now on a few distros of Linux and Windows, I don't own a Mac so I cannot test that for you. What platform does shift not invert the case to lowercase if capslock is on?
Who in the right mind thought that would be a good idea? It seems like the type of case where some executive though that failed password attempts would increase customer support load by 0.1% and therefore decided to make it a lot easier to log in. But in that case, why did they decide to stop at 8? I feel like they would have made passwords a 4 digit pin if they had their way.
Probably someone working on a limited mainframeish type computer in 1964 when many terminals didn't support lower case and the memory to store passwords was expensive. The idea of encrypting the password probably didn't exist in those days either. None of this mattered because all the terminals were inside their building so you had to get by the guard to get in. Best practices have moved on many times since then.
> Who in the right mind thought that would be a good idea?
Someone who doesn’t care or know or care to know. If the company (or manager in some cases) doesn’t treat people right they may not do anything above the bare minimum to survive.
So the next time a problem comes up, e.g. the old password field in the database only holds 8 characters but someone sent a memo around requiring users to provide passwords of a certain length, they might just truncate the input - problem solved, now back to lunch. Or if they would have to argue or fill in a form for a new database, they might just not do it. It could even be that they have incentive for this, e.g., easier to get raise if they don’t ask for new task related things all the time.
Whenever something stupid happens I’m reminded of the movie Office Space, this happens even at FAANGs.
> they would have made passwords a 4 digit pin if they had their way
There’s a well-known bank in Australia that has been doing this for years [1]. It’s very convenient, and if there was a significant fraud risk associated with it, you’d think they would have changed their policy by now.
My favorite is silent truncation on the signup page but not on the login page.
> I paste in my password. It gets cut off to N characters by the form.
> I paste that same password on the login page. There is no character limit on the login form.
A shitty local bank back home truncated without telling you as well. Didn't realize it until they rolled out a mobile app and my password didn't work. After complaining about it, a friend who worked at said bank as a teller said to try truncating to 8 chars and it worked. :rage:
Apparently it was known internally, as they used some ancient system behind the scenes that would only support a max of 8 chars, and the website just truncated your password and passed that on. The new app didn't truncate and would get an error response.
> An old credit union I was part of in NY (SEFCU) mandated passwords with exactly 6 characters. When I complained about this I was told it was secure because they forced one of the characters to be a symbol.
For a bank?! And here I am complaining that Chase doesn't support application-based OTP. I hope you ran far far away from that CU.
I forgot my password for a credit union back in the day (before I started using a password manager as we all have so many online accounts now). I clicked the "Forgot password?" button... and they sent my original damn password back to me, in email. There are just so many things wrong with that. I complained, actually talked to their "technical people" and explained the awfulness of it, then moved all my money out of that credit union. They did change how it reset later, as another member had told me, but I bet they still stored the plain text password. I was seriously angry with their awful security.
Funny thing about Fidelity -- if you call them to deal with an account issue, the automated phone system asks you to enter your account password using the phone keypad. And it's quite impatient (I wasn't a third of the way through my 32-character password before it gave up and transferred me straight to a representative!)
There was a "bug" a few years back in Dell iDRAC that silently truncated the password. Took a number of support calls and ticket escalations to get them to recognize it and patch it. It occurred to me then that if Dell's enterprise team did it that it must be much more rampant than I've seen.
iDRACs aren't supposed to be public, and are on average far less sensitive than a bank account, so all in all, not that bad. And considering the quality of Dell software, it's actually better than most of their useless pieces of crapware.
Security risk or not. Changing your password on the idrac and it not being what's expected and having to jump into a DC to change 30+ host iDRACs was not ideal.
All because I couldn't find the bug at the time, I read it a few weeks later only after over a week of back breaking basic sys admin work.
Small bonus. It built my use case for fucking off more on premise infrastructure into the cloud.
Maximum length makes sense if the hashing algorithm they're using does not go past that length. I think this puts your 1st and 3rd bullet points at odds in some cases, if I understand your point correctly.
I'm not looking this up right now, but I believe bcrypt or some 'version' or 'implementation' (excuse the inaccurate language) of bcrypt limits you to 72 characters. If that limit is not made clear to the user, then they may find it odd when their 73+ character password can have the last N-72 characters changed and still successfully log in. Silent truncation is most likely a result of ignorance on the part of the software developer (I'll admit I did not know about this limit for a long time), whereas maximum length could be the opposite.
You can solve this limitation yourself by implementing a simple client side digest hash before sending to the backend for proper password hashing. So your backend receives the fixed length digest hash and not the actual password for hashing. With a good digest hash algorithm like sha256 you are effectively able to support "infinitely" long passwords without any significant loss of entropy.
>like sha256 you are effectively able to support "infinitely" long passwords without any significant loss of entropy.
I disagree. I used to have my password manager generate long passwords, but I realized that the entropy was just being clipped to 256 bits by the hash function. It's not that crazy to go over. That being said 256 bits of entropy is plenty.
The problem with this approach is that now someone on the backend will mistakenly think, hey the password is already hashed by the client, let's just store that directly in the database! And now you essentially have passwords stored in plain text.
> like sha256 you are effectively able to support "infinitely" long passwords
If my math is correct, 256bits of hash can effectively support up to about a 36-character password, depending on how many bits of entropy you give each character.
Your math is incorrect. Sha256 can support arbitrarily long inputs. You can easily verify this claim by googling a Sha256 calculator and giving it 2 inputs
: First your 36-character "password" and next the same password with an extra character. You will notice that the outputs will be different.
With a password longer than about 36 characters, the pigeonhole principle comes into play, and there will exist a sub-36-length character password with the same hash as the longer password.
Right, but that doesn't refute the original point: you can support infinitely long passwords by hashing them. If we compare truncating a password to 36 characters vs hashing a password to a 36-character hash, hashing is much better. The hash is guaranteed to have at least as much entropy as the original password, up to 36 characters of entropy (yes, the hash can not have more than 36 characters of entropy, we get it, that's not the point, nobody is brute-forcing passwords that actually have 36 characters of entropy).
I'll provide an edge case example to prove my point: suppose someone has a password that repeats the character 'q' 100 times, then repeats the character 'a' 100 times, and so on, until the password contains 8 randomly selected characters. This password has (slightly more than) 8 characters of entropy, right? If you truncate the password to 36 characters, the password will simply be 'q' repeated 36 times, so the truncated password will have (slightly more than) 1 character of entropy, right? But if you hash the 800-character input to a 36-character hash, the hash will contain exactly as much entropy as the input: (slightly more than) 8 characters worth.
Maybe the example with 36 characters doesn't seem realistic to you, but my previous bank (Handelsbanken) actually secretly truncated passwords to 8 characters. I was not aware of this, and I had a password that contained multiple consecutive words (like correcthorsebatterystaple). I thought I had a secure password, little did I know my password was actually a single word because of the truncation. Now, if my bank had instead hashed user inputs to an 8-character hash, and used that as the password to their legacy system that only supports passwords up to 8 characters, my password would have actually contained 8 characters of entropy.
Yes exactly. Hence the quotes around the infinitely.
Your chances of starting out with more entropy in a 800 char passphrase is likely to be larger than what you are likely to have when starting with a 36 char passphrase.
If you hash a 36 char passphrase then you retain most of the entropy of that 36 chars. No more no less. If you hash a 800 char passphrase then you maintain most of the entropy of that in the resulting 36 chars. Which is likely to be more.
But that’s not what Sammi described as “support” upthread: “support "infinitely" long passwords without any significant loss of entropy.”¹. That description – i.e. “without loss of entropy” – is what I took issue with, due to the pigeonhole principle.
Personally I don't think there's a practical difference between having 1000 bits of entropy in your password versus 256 bits of entropy, but fair enough.
Ha, funny to see my old bank from college mentioned on here. For what it's worth, their site seems to be a lot more reasonable about passwords nowadays.
> An old credit union I was part of in NY (SEFCU) mandated passwords with exactly 6 characters. When I complained about this I was told it was secure because they forced one of the characters to be a symbol.
Woah that's so secure. What if you only had 2 characters; both symbols. I'm sure that is 2x as secure.
Yes, it gets more secure as you add more requirements. Let's mandate that last character is a digit larger than 1, but smaller than 3. Also, the password must be exactly 7 characters long, and the first 6 characters must spell out a class in WoW, lowercased.
The article kinda misses the reason why mandatory password changes existed in the first place -- unknown breaches. The idea was that if there was an undetected breach, the attacker would have a maximum of the mandatory password change to use credentials. You would still have mandatory password changes upon discovering a breach, which would reset the counter. And the article wasn't very clear as to why this is no longer recommended, but when mandatory password changes are enforced, users tend to make new passwords which are trivial to crack if you have a known old password. So if there's an unknown (or even known) breach, users will tend to make a new password which an attacker can easily guess given the older known passwords, losing any benefit gained from mandatory password changes. And this is worse than not having mandatory password changes, because rare password changes (when a breach is discovered) don't put people into the habit of just iterating off of an old password.
A better focus for security efforts is detection of compromise. For example, say you detect a user has signed in from 2 different countries in a short window or perhaps malware signs are discovered in their cloud storage. Perhaps MFA is failing often for a user meaning an attacker is successfully using a password but is unable to get past confirmation on the user's phone.
This is the key. With Okta for example, you can configure a maximum velocity for a user for Behavior Detection to trigger additional scrutiny on a login. That type of stuff is useful.
How well does this handle things like logging in from mobile devices? If I logged in from my desktop and later from my mobile phone I would appear to zip 350 miles because my mobile data exits the phone network 2 states and 350 miles away.
Your phone's IP address isn't related to your phone number. For IPv4 addresses it'll probably go through the closest CGNAT gateway on the phone network.
Checking geo IP services on my phone usually put me in roughly the same metro area that I'm physically in despite my area code belonging to a city hundreds of miles away. That said, I just tried a lookup on the cellular network on Maxmind and it thought I was in the next state over (a couple hundred miles off).
IP geolocation services usually aren't as great as what people think. My residential home IP had probably previously belonged to some Canadian ISP as things that would base their defaults off a detected geo IP lookup would think I was in some small town in Quebec despite living a thousand miles away. IP addresses change hands, people connect through all kinds of proxies and CGNAT gateways, location databases get old.
> Your phone's IP address isn't related to your phone number.
I'm not basing it on my phone number that's for central NC and from 10 years ago, I'm going off of the geoip and the fact that I get tons of ads or sites defaulting to Atlanta for weather or local store searches if I don't allow them more device based location data.
Not sure about Okta, but systems I've seen in the past (fraud detection etc) will quickly learn the pattern and not challenge you as often. It depends a lot on the data points the system uses to calculate risk as well as any configurable thresholds.
In this hypothetical I'm logging into the account from two different devices, one connected through the local ISP and the second on a cellular network (either through a hotspot or directly from my phone it doesn't matter). My IP for things going through the cell network get an IP that is located by GEOIP as being in Atlanta while the local ISP would locate to the RTP area of North Carolina.
I thought that now every cellular provider actually does this so when you move between networks your IP address stays the same as otherwise all your connections would break during handover; and not breaking connections is basically mandatory since voice over LTE, because voice calls now run over IP protocol too and seamless handover for voice is expected by users.
You're usually pretty heavily NAT'ed on a cellular network. Your internal IP address probably doesn't change much but external IP addresses probably change a good bit.
I am not a network guy at a cellular company, but IMO it would make more sense to use a more local gateway for outgoing connections rather than potentially routing things all the way across the country. These days people keep their number but move all over the country. It would be insane to have to route things back home every time.
do attackers wait to use passwords months after they've compromised those passwords? or, do they give themselves other ways to maintain their access so that no passwords stand in their way from that point on?
it's the latter, not the former. once you're compromised, passwords, changed or not, are no longer an obstacle at all.
Unix-like OS in 80s-90s truncated passwords to 8 bytes, hashed in MD5 and stored them to regular file `/etc/passwd`. And in those era it was estimated to take six months to few centuries to brute force a password, therefore it was recommended to maximally complicate the password within 8 letters in length, and change it every one half the brute forcing time, or three months. Supposedly everything made sense in that timeframe in that context.
A 1979 UNIX /etc/passwd file surfaced a couple of years ago (it's on Github[1]) and people tried to brute force the passwords; Brian Kernighan's was the weakest. Ken Thomson's took "more than four days on an AMD Radeon RX Vega64 system running hashcat ( a password cracking tool) at about 930MH/s (Million Hashes per second)" and was the last to fall.
> Unix-like OS in 80s-90s truncated passwords to 8 bytes, hashed in MD5 and stored them to regular file `/etc/passwd`.
In the era when password hashes were still readable to everyone in /etc/passwd (this was later fixed by storing the passwords instead in a shadow file called /etc/shadow which can only be read by root), it was not MD5, but "crypt" (a DES variant). AFAIK, the MD5 and newer password hashing schemes don't truncate the password to 8 bytes, only traditional "crypt" did that.
Really depends on the level of access the password gives you.
If you're infiltrating a company, most people's accounts certainly don't give you the level of access required to bypass the need for passwords entirely. You'd have to be specifically hacking a sysadmin's account or something.
There are very many different levels of "compromised" and they're not all the same.
That being said, I agree with the overall premise that password rotation is outdated.
I once read a book where an attacker accessed a live system with a set of compromised credentials, then found some "disabled" accounts from retired staff, re-enabled them, then simply used the retired accounts for routine access. Sventek was one of those, I think.
Hi, attacker here, I usually use the password immediately but it really depends on the level of user as to whether I can ensure that password changes won't affect me going forward. If you're a normal user, changing the password is helpful. Root? Forget about it.
Actually the fastest possible way to detect unknows breaches on the user side is to show your last login time. (On the server side is looking for IP patterns)
I think approximate location would be a good idea too. I wouldn't remember the last time I logged in to many important services since I do it so often. Relatedly, I have trouble remembering when I paid for so something so just looking at my banking log for fraud requires me to see who the payment actually goes out to.
Unfortunately, a lot of us are using VPNs now. So, location isn't a very good indicator as that would provide a lot of false positives. That actually happened to me recently, and I though "Oh yeah, I was using a VPN then." So, that indicator is just getting worse as I use a VPN on my phone all the time now.
In theory, but in practice some accounts are only rarely accessed by their intended user (might not log in for months at a time). And on the flip side, it's really easy to ignore the displayed last log-in time/IP/location altogether.
One of original motivations for password expiration was the belief that if your password DB was stolen, you had some significant amount of time before any malicious party would be able to crack a password and use it. That is no longer true: it's extremely likely that at least one user in your system has a password that is trivially cracked or in a rainbow table. Your system is vulnerable in a day, or less, after you've had your passwords stolen.
Rainbow tables are essentially instantaneous so one day isn’t enough either. If you care about that kind of scenario I’d say your energy is better spent on just picking a more suitable hash algorithm.
Absolutely. In the real world there's just no case for password expiration any more. Require at least 14 characters. Don't insist on any "complexity" rules, but do check passwords against a list of of common/stupid ones and reject them. Use a good hash algo, like bcrypt, scrypt, or Argon2
Yeah, I think there's value in it, but if you don't have a way to prevent "plus one passwords", it probably isn't super effective anyways. It may be a case where frustrating the user four times a year isn't worth it... maybe just frustrating them once a year will lead people to put more effort into making their passwords suitably different.
Four times a year? I've had to change mine once a month for the past 20 years. Needless to say, I increment a numeric suffix that wraps around every 10 or so months.
It has always seemed like a totally pointless exercise.
I can see potential value for service accounts, as long as you have automation in place to change them where needed - but for user accounts, it's complete madness.
Hum... I have never seen any place that implemented password rotation for the users and didn't exempt service accounts. And the security solution sellers I've talked to are all either on the position of "yeah, password rotation is incredibly important, but you can't rotate service accounts" or "yeah, I know you don't rotate the password of service accounts (no need to tell me), here's a tool to reduce the risk this causes".
Microsoft's approach now is to recommend using Managed Service Accounts, which is an Active Directory feature in modern Windows servers. They rotate their own passwords through some sort of magic. That being said, plenty of janky old Windows apps won't work with them anyways.
Place I work started rotating service account passwords around a year ago, using automation built in to some super expensive PIM (Privileged Identity Management) system.
Just to complement, so next time I can say I heard about one place on the internet... Does your workplace require password rotation for personal users?
Yes it does - something like once a month. And every.single.employee is going to be incrementing a numeric suffix, providing no increase to security whatsoever, and annoying the hell out of every.single.employee. Actually, it probably weakens security, since employees will be more likely to have notes of their current password around, since it's difficult to remember the current suffix, since it changes so damn often :/
My "friend" doesn't use this system anymore, but passwords along the line of '1stQuarter2001!' worked for well over a decade of being required to change passwords 4 times a year.
Am I the only one bothered by month ordinal 04 assigned to March, which is the 3rd month? This sounds almost like Java's infamous Date class that assigned month ordinal 2 for March, except somehow we've managed to make the off-by-one error in the other direction :D
There definitely is value in it if users created proper passwords, but path of least resistance tends to win out in the end, and people will just find ways around the mechanisms to prevent weaker derived passwords.
It does not seem that difficult to detect when the new password is very similar to the old password. Do it on the client side on a page that the user enters both the old and the new. And give the user guidance to use a password manager and auto-generated password.
Not true. If you have the new password, and old salt and hash, you could change a few things in the new password (common things, like increment or decrement a number if there is on the end), and hash it with the old salt. All this would be done when updating the old password.
Proper password change procedures generally require the old password to update it, so the code running on that page theoretically has access to both and can run a similarity check.
But my opinion is that ensuring creative passwords with an unclear similarity rule will only result in creative bypasses of that rule.
Unfortunately it's an easily defeated method. The motivated user just changes their password to a temporary value, and then again to the incremented value.
A user can also trivially defeat any password system by publishing their password to Facebook.
The purpose of preventing similar passwords isn't to prevent a user from defeating themselves, it's to prevent an adversary from defeating the user.
Now you can rightfully argue that blocking similar passwords isn't an effective measure against an adversary, and this article kind of suggests that... but it is possible to implement such a system.
I've been at places where the old passwords seemed to be kept around, so that it was detected whether or not you were switching to the password you used six or seven passwords ago.
This is done by keeping the old hashes around. The new password hash is compared to prior hashes to be sure it doesn't match any of them. This only catches exact matches on re-used passwords.
Or, the current plaintext password is compared to the new plaintext password (normally a password change requires the current password) so you can do more sophisticated similarity checks, but only compared to the current passord, not any older ones.
The whole point of this article is that rotating passwords is pointless. It doesn’t solve the original problem. MFA is the solution to that problem, not password rotation policies with Byzantine change requirements.
A better focus is on plugging the hole where the password was stolen. If it’s not plugged the password will simply be stolen again.
The reason rotating passwords is pointless is because people always end up changing their password to some easy to guess variation of the original password. If you prevent that from happening, the new password won't be guessable if you have the old one.
If I recall correctly: Active Directory can be setup so that the last few passwords cannot be reused, otherwise people would just cycle through two passwords. I am guessing that people would simply use a variation of their second to last password to come up with a new password under your proposal.
A long time ago as a student I worked at a company that had mandatory password changes every month. So I just used the same password and appended the current month to it.
It sounds good in theory, but in practice rotating passwords really doesn't help much. You alluded to it in your last sentence, but if you require password rotations, say every year, a lot of your users will end up using:
basepassword-2021
which they will change next year to
basepassword-2022
Because password hashing makes it impossible to retrieve the original password, there is no way to guard against people just using a basepassword and appending some type of counter to it.
Thus if there really is a breach where the plaintext password is recovered by an attacker it is trivial to find out what this year's version is.
So all you end up doing is needlessly irritating your users, for not much security.
Multifactor Authentication is a much better solution for the issues of unknown breaches.
> Because password hashing makes it impossible to retrieve the original password, there is no way to guard against people just using a basepassword and appending some type of counter to it.
Almost all the implementations require the old password when you change it to the new password, so it's trivial to check if they are too similar.
def changePassword(login, cleartextOld, cleartextNew):
if too_similar(cleartextOld, cleartextNew):
return new Error("too similar")
hashOld = hash(cleartextOld)
hashNew = hash(cleartextNew)
if authorized(login, hashOld):
setPassword(login, hashNew)
return new Ok();
If you're afraid of sending cleartext passwords - do the too_similar check on the client side. The users that can write their own client to bypass client-side checks are exactly the users you don't need to worry about.
A user could defeat this by changing to an intermediary password and then incrementing the original. E.g. sign in with current password "cat100", change it to "dog100", then sign in as "dog100" and change to "cat101".
The system can just store the last n passwords (salted and hashed, of course) for each user. I seem to recall some software I had to use in college wouldn’t let you toggle between passwords like this.
Ah, but one could write a script to change password n+1 times.
That's why, to encourage users to assume last month's password was compromised, when my users change their password the old password is automatically posted to twitter
Unless you generate all the password variations upfront and salt+hash them all! I think I’ve heard that some place (maybe Facebook?) does this for common password entry mistakes like capitalization.
> there is no way to guard against people just using a basepassword and appending some type of counter to it.
Sure there is. In your update logic, decrement any numbers and check the hash against the existing password. Alternatively, require the existing password in the same form and you don't have to check against hashes, since you have the plaintext password right there.
I think you underestimate people inventiveness when it comes to circumventing these types of systems.
People will either keep trying new strategies to embed counters in their passwords (maybe increment a letter, or multiple a number by 10), or they’ll just write the password on a post-it they keep on their laptop.
Either way you’ve now got a whole load of complicated code that makes it harder to people to create genuinely strong and memorable passwords, and no additional security.
> Alternatively, require the existing password in the same form and you don't have to check against hashes, since you have the plaintext password right there.
Presumably, you will also have a forgot password flow that allows you to change your password without entering the old one.
People will make things easy for themselves. Coming up with good passwords is hard. Having to rotate passwords just seems like a lot of busywork and people will make it as easy for themselves as possible.
Couldn't you hash some obvious variants of the new password to test against? I always assumed this system did that since it would reject some passwords that were close to old passwords.
Of course, it's also possible they stored the clear text password, I have no real way of knowing.
> Couldn't you hash some obvious variants of the new password to test against?
This is impractical if you're following good password storage practices. Assume the user's new password is 16 characters long, and that only the 95 printable characters are allowed in passwords. Then to test that the Levenshtein distances between it and the user's last 5 passwords are all greater than 1, the server would have to compute (5 * (1 + 95 * 17 + 16 + 94 * 16)) = 15,680 different hashes, which will take quite a while if you picked a secure iteration count for your password hashing function. And even if you did this, it still couldn't detect mypassword100100 -> mypassword101101 -> mypassword102102, etc. (Making sure the Levenshtein distances are greater than 2 would require checking millions of hashes.)
> Because password hashing makes it impossible to retrieve the original password, there is no way to guard against people just using a basepassword and appending some type of counter to it.
> Thus if there really is a breach where the plaintext password is recovered by an attacker it is trivial to find out what this year's version is.
Off topic for password rotation, but has anyone tried assigning randomly generated passwords to the users rather than letting them choose their own?
People (including me) _hate_ memorizing things and would probably write an assigned password down, but isn't it better to expose passwords to nosy coworkers than to the whole internet, as is so often the case with weak or reused passwords?
> has anyone tried assigning randomly generated passwords to the users
We do that. We generate long random-character passwords (both for e-mail, web sites, and other accounts), and we don’t provide any online way for users to change them. If the users need to change a password, they have to contact us to do it (which is reasonable, since a big part of our value proposition is our responsive support). We only very occasionally even get such requests, and even more seldom get requests from users to set their own passwords. So far, everybody has been perfectly satisfied when hearing “No, users don’t set their own passwords. We can generate a new one for you any time you like.”.
This policy has been in effect since before my time, and I have worked here for more than 10 years. During this time, there was one user who really wanted something more memorizable for a specific account, so I set a correcthorsebatterystaple-style password on that account only. One other user had trouble adding the password to their password manager, and I had to help them do that. Otherwise, no problems.
That's been our practice, for the reasons you describe, and we also take steps to make the passwords memorable (while retaining sufficient resistance to cracking). We also tell users that if they write down the password, don't write 'password' or the username or anything else on the paper - you will know what it is - and don't put it someplace obvious (on the monitor, under the keyboard, etc.).
Would it be a bad idea to salt and hash probable increments of a password when it is changed? For example, password would be salted, hashed, and stored along with Password, password1, etc.
Then the system could reject these on the next password change without storage of the original plaintext password.
It's no longer a recommended industry standard, but unfortunately, it is still basically required, because many compliance policies have not updated. I would be shocked if at least some of Microsoft is still required to employ password rotation policies because of their own compliance requirements.
At least one policy I am looking at maintains the 90 day rotation requirement if you use basic password authentication, but offers alternative options for compliance with other authentication features. But even most of those tend to have yearly rotation requirements.
I suspect Microsoft uses JIT policies for accounts that would be subject to password rotation - you have a separate account that has access to sensitive data, but it's normally locked. When you need to do something, you initiate an access request that requires either a smart card or hardware security key. Depending on the type of access required, another person may have to ok the request. Once approved, the account is unlocked for a set period of time with a new password.
Recently had a long discussion over email with an executive security officer of my company regarding this topic. Their conclusion was basically "until the standards change this is how it will be".
Isn't it weird when all of us individually knew forced password change is more harm than benefit, but it took literally decades for this to become institutionally admitted?
Just imagine, maybe a subset of neurons inside your brains have amazing ideas that could change your life, but it might take decades (or never) for them to surface to the conscious level where you realize "oh, I have an idea".
How to make sure organizations are not less than the sum of their parts?
> Isn't it weird when all of us individually knew forced password change is more harm than benefit, but it took literally decades for this to become institutionally admitted?
The US bank I recently opened an account with (in 2021) is in the S&P 500, publicly traded. The only form of 2FA they support is SMS or some proprietary hardware keychain LCD thing they don't give out for free (which I assume is the M+A great grandchild of those RSA TOTP fobs that were the fad in the 90s).
It's not weird. Most security organizations are wholly incompetent, doing cargo cult security nonsense "because that's the way we've always done it".
Best password policy I ever lived under was the graduate computer lab at the university. The admins just left a password cracker running continuously, and when it got your password, it was time to change it.
The company I work for is one of the large(est) “FinTech” conglomerates. After talking to a lot of our security folks they agree about not changing passwords but are unable due to PCI and Federal standards/audits.
We have to adhere to outdated security practices simply because the auditors will flip out and the documented controls in government mandates. Section “10.12.3.4” says you must rotate passwords.
I welcome websites removing mandatory password rotation. And it's true that rotating passwords doesn't necessarily reduce the chances of having it brute-forced. But that's not the point of changing passwords every so often. Rotating passwords is useful because a security vulnerability in the site or some mistake on your part can get the password exposed. You're not trying to protect yourself against super hackers (that's the website's responsibility), but against your own mistakes.
I can't honestly think of any website that enforces password rotation. Except for corporate application websites, which I would consider application's that fall under my companies password security regime.
I wouldn't want to image a world where every website would force me to rotate my password, each with it's own interval and method. Imagine the upkeep time cost.
Many of my banks do password rotation forces - one which annoyingly requires you to update your password if you haven't logged in in 90 days - but doesn't count Touch ID on their app as a login.
Almost every .gov I work with requires it regularly, along with account deactivation if you haven't logged in very recently.
There's one particular website I have to log into exactly once per year. I have monthly reminders to log into and change my password anyway, lest I have to create a new account 10 months later.
And yet, there are Fortune 100 financial institutions that require their vendors to have a policy of mandatory 30 day rotation for sysadmins and 90 days for non-privileged persons. Companies that don't have and enforce said policy are unqualified for the privilege of vendorhood. Pointing out this Microsoft paper, the NIST guidelines, or the NCSC guidelines will just get the subcontracted droids giving you a negative mark on your annual vendor security assessment.
No, I am not jaded or bitter on this topic. Why do you ask?
Mandatory password rotation does help in one place - when passwords to an account are shared.
So if Microsoft Employees 1,2,3 share a password to Vendor X's system, and employee 2 moves to another part of the company or leaves, the shared password will eventually change and employee 2 won't know it anymore.
Not talking about feature support in an app. Employees of companies which contract with Microsoft must rotate their passwords. (In addition to attending mandatory training, using an anti-virus, etc)
Microsoft has been saying this since before FTA, but nobody seems to have told corporate IT. When I was there (2015-2019), we had to change our passwords every six months.
Security consultant here - I put it in many of our reports (whenever we notice such a policy). They're not exactly changing course just yet, but we do try to communicate the good news where relevant. Also to avoid complexity requirements ("you don't have any digits in correct horse battery staple, that cannot be secure!") but to use a blacklist and length requirement instead, as recommended by NIST and NCSC (hopefully other countries will follow suit).
Tbh I don't trust passwords to keep my accounts save, it's 2FA all the way.
Passwords have this nasty tendency to get leaked, one of my older e-mail accounts is listed in 12 different breaches on haveibeenpwned.com
And while the ideal is not to reuse passwords, keeping that practice up with the number of accounts that are nowadays required with a somewhat digital lifestyle is kind of impossible, short of using a password manager.
But then you are locked into a password manager and gotta hope it works on all the devices you gonna need your passwords on or else you will be stuck manually putting in long and complex passwords.
I would go further: "passwords are ancient and (should be) obsolete".
If you can don't rely on passwords, use hardware security keys and protocols like U2F and other FIDO2 related protocols. Sure you might still have a pin, but now you rely much less on it so it can be much simpler.
If you can't use word phrases instead of passwords, e.g. 4 randomly selected words, and yes randomly selected for the user, not choose by the user. But with a way to "re-roll" when setting the pass phrase.
As a side effect of being more secure (then normal remembered passwords) and easier to remember. As a benefits they are also easier to insert on phones with swipe keyboards and have some nice tricks wrt. internationalization you could use. (Make sure they
still work with password managers.)
Practically maybe not possible currently, but if you already rely on a password manager there is technical very little reason not to replace passwords with a U2F/FIDO like process connecting to the password manager. This might be less secure than a HSK but still nice. Ah, anyway that's currently not a think.
Lastly if your service isn't generally "security sensitive" and login sessions tend to be long consider login links send to your password reset email. Especially if combined with password-less fido auth based on the browser + TPM this can be a nice approach (you use password-reset-like links to setup password-less fido auth on the given device).
If you have password rotations forced in Office 365, it will actually prompt you at the admin page with a recommendation to turn them off. There's documentation here:
Mandatory password changes never made any sense. It's especially terrible when systems don't allow users to re-use previous passwords.
It forces users to keep inventing new passwords which they can never remember, then they end up writing the passwords on post-it-notes and sticking them on their computer screens where everyone can see.
Same issue with forcing people to use special characters in their passwords; it makes people choose passwords that they can't remember.
I've used systems where the situation became so out of control that I literally had to go through the entire 'forgot your password' (reset password) flow every single time I wanted to log in. That was the fastest way for me to log into that service.
I knew an old hack IT guy who had a spreadsheet full of users passwords which he obtained through demanding them when their computers needed fixing. Rotation dealt with that particular issue!
Then somewhere else I read an IT policy that said 'You will be assigned a password by IT, do not change it.'
I have seen numerous cases of IT support asking users passwords to make fixing a machine more permanent. I have seen more than one where they kept that record.
I have also seen lots of cases of, 'I have their passwords so I can log in to their email when they are away'. We know it is stupid, but these smart people didn't.
That is why I still rotate passwords, I know some will be compromised internally. I do it on a slow schedule though.
The fact that all of those are created to circumvent some other stupid and baseless security policy speaks loudly. (Except the second, that one is the policy itself.)
> Microsoft employee Aaron Margosis said the requirement is an “ancient and obsolete mitigation of very low value.”
That kind of magical thinking is what got us mandatory password rotation in the first place.
Password rotation has a kernel of truth: automated credential rotation really works, and sometimes you need to force manual rotations to migrate to a newer hash algorithm, and I'll bring up another reason for it.
But the main reason we have password rotation is people have some magical belief that a credential gets "old" so we have to freshen it up.
Security rules are the same: they work, or they don't, and that can be very complicated due to human factors. But they don't "get old" and magically lose their effectiveness. If password rotation is broken, it's always been broken.
> Chief among them, the requirements encourage end users to choose weaker passwords than they otherwise would. A password that had been “P@$$w0rd1” becomes “P@$$w0rd2” and so on.
Not true. If they hadn't been forced to rotate, they would have stuck with P@$$w0rd1 the whole time, and P@$$w0rd2 is not weaker than that.
> At the same time, the mandatory changes provide little security benefit, since passwords should be changed immediately in the event of a real breach rather than after a set amount of time prescribed by a policy.
There is a clear benefit, especially for large enterprise systems: a periodic password change does put a limit on when the attacker could have used the password.
So when a credential is exploited, if you're rotating yearly, you only need to search back at most a year to figure out the scope of the breach.
I don't know how much of a benefit this is, in practice. Maybe someone who has done a real log dive can comment.
The only certainty is that you must never have passwords older than logs.
> If it’s a given that a password is likely to be stolen, how many days is an acceptable length of time to continue to allow the thief to use that stolen password?
Rotating (or required change) on some circumstantial criterion (the old password is know or suspected to be compromised, system update, etc.) is entirely valid.
Forced scheduled frequent password updates are not and worsen rather than improve security. That's the point here.
In environments in which data leakage probability is high, and detection capabilities poor, periodic password changes are a defensible risk-mitigation measure, though in practice unless new tokens are themselves robust, the practice backfires. The problem is that both sides of the risk calculus need to be considered --- compromised token validity period, and token strength. People being people, the first is actually the safer risk to take.
> Not true. If they hadn't been forced to rotate, they would have stuck with P@$$w0rd1 the whole time, and P@$$w0rd2 is not weaker than that.
The thing is that with the requirement you can guess the last one or two characters of pretty much the entire user base. Also, if you’re constantly changing your password it possibly means that people have to type it in more often, which can lead to shorter passwords too.
I blame Microsoft for most of the password policies my company implemented years ago and won't change. Mandatory password changes included.
While on my soapbox, I'd like to tell them that it's really dumb to count multiple attempts of the same password individually and then lock you out after you attempt the same password three times. And your most recent password should count as zero attempts. These kinds of dumb policies only hurt legitimate users and do nothing to improve actual security.
Rotating passwords every so often is good advice, and I find it unlikely to discover a good reason not to.
With a password manager, this process is pretty painless, if not automatic.
Mandating it for my Hello Kitty: Island Adventure account seems a bit heavy-handed though.
Rather than pulling back the recommendations, we should really be implementing open standards for automatic rotations that don't rely on reverse engineering / implementing various third party reset password flows.
I should add that a password which you actually need to remember, like the master password to a password manager, should never be used online. The more isolation you can maintain the better. This way offline attacks against stolen hashes are unlikely to find anything, since they will only contain randomly generated passwords.
Debunks?! More like claims that I will most likely reuse or slightly modify the old password.
> The same researchers have warned that mandating password changes every 30, 60, or 90 days—or any other period—can be harmful for a host of reasons. Chief among them, the requirements encourage end users to choose weaker passwords than they otherwise would.
That is incorrect in my case since I generate random passwords, and no other evidence is cited. I would be curious what other reasons they have in mind.
I agree in general, most people may not have password managers still, but that seems like the problem to be fixing, rather than relaxing security advice.
Specifically, password managers for login passwords is a bit of a tricky subject, but that's why I hate the idea of "live" accounts, where my login password and online password are the same.
A while back I was tasked with getting hundreds of our companies computers back online after a ransomware incident bricked them and for that I needed users passwords. Our company mandates quarterly password changes and as a result I was blown away how many people had some variation of "{company_name}{season}{year}" as their password. I'm convinced these mandatory password changes do more harm than good.
Ideally passwords would be phased out in favour of hardware backed authentication. We all have at least one device supports authentication methods like: fingerprint login, face id, FIDO2 tokens, etc. Why not use these instead of passwords for applications/websites which require single-factor auth.
A wearable NFC ring still strikes me as one of the best options.
- It's something on your body, you'll notice if it's not there.
- Unintentional use / involuntary use is relatively rare.
- The hardware token can still be paired with other metrics (password/passphrase, PIN, biometrics, secondary device, OTP, geocode).
- A duress code can be included. (Memorable duress codes ... are another matter.)
- The NFC ring is itself replaceable. This solves the "ten fingers" biometrics replacement/rotation challenge. (Count Rugen gets a bonus.)
- A "ring tap" can be incorporated reasonably into most authentication workflows.
- Those unable to wear a ring directly will likly have other options that should be suitable (amputees, paraplegics, motor-neural disabilites, etc.). Disabled access should be pretty high, especially relative to altnernatives.
But yes, the initial assumptions surrounding password-based security at MIT in 1960 are all but entirely voided in present usage.
"Recent scientific research calls into question the value of many long-standing password-security practices, such as password expiration policies, and points instead to better alternatives such as enforcing banned-password lists (a great example being Azure AD password protection) and multi-factor authentication."
MS acknowledges and supports this, yet ad still doesn't support banned lists without serious modification and customization to ad. which no sane ad admin will allow.
I think ms is finally starting to abandon on prem ad, in favor of the less capable, and less tested azure ad. it is a shame that a staple of enterprise it is slowly dieing out without a real replacement.
Password expiry policies are useless. No one recommends using them. As has been pointed out already, the standards orgs and government cyber security departments advise not to have expiries. However most enterprises (I did a straw poll of all my friends and people they knew) still do it. I wrote about it here: https://jgandrews.com/posts/password-expiry-policies-dont-wo... back in January. Nothing makes sense about password expiry.
> Researchers have increasingly come to the consensus that the best passwords are at least 11 characters long, randomly generated, and made up of upper- and lower-case letters, symbols (such as a %, *, or >), and numbers. Those traits make them especially hard for most people to remember.
in other words, the only good password is a randomly generated bitstring (just like a key!) represented as some weird almost but not quite total subset of 8-bit ascii that was based around some weak and wild assumptions that human generated text is not guessable.
> Researchers have increasingly come to the consensus that the best passwords are at least 11 characters long, randomly generated, and made up of upper- and lower-case letters, symbols (such as a %, *, or >), and numbers. Those traits make them especially hard for most people to remember
Sounds pretty wrong to me. I think when they say "the best passwords" they mean the hardest to crack. But a password that you need to remember that's hard to remember is not a good password. It doesn't take much research to understand that passphrases are the best kind of password. 4 random words (if throttled, 5-6 if not eg for local encryption). It's a bit silly to me for this article to imply these people are spending years researching passwords, and this is what they come up with. We need to switch to client side certs already. Passwords for websites are obsolete.
If you're using a password manager, shouldn't you just have it generate a random strong password you don't expect to remember? If you're remembering it, it's really best to not use noise, just plain correctly spelled lower case words. Adding an additional word adds both more security and is easier to remember than adding an ampersand somewhere in your password
What it generates you have control of. So you can say "I want uppercase, lowercase, numbers, characters, of length X". So the guidelines are still relevant.
The only thing you should remember is the password into your password manager, and if you want to add more words, by all means; I just find it quicker to type, no harder to remember, while making a dictionary attack unfeasible, by adding a character or two to the passphrase. I.e., "correct!horsebattery,staple" (though I agree that at four words you're fine anyway; I'm just saying that with a little noise thrown in I can type two or three words, plus a couple standalone, easy to remember characters for the same level of complexity)
Mandatory password changing leads to only one thing: password rotation.
I had a bank that expired their online banking passwords every 30 days (in spite of also having 2FA via physical token ON TOP OF THE PASSWORD). Guesss what, my password was word-number-word. I just incremented the number 10 months, then reused old numbers.
Incidentally they rebuilt their online interface and changed the tokens for new ones. The password doesn't seem to expire any more but it's still required for some reason.
One of the things I used to hear cited "back in the day" was that things like the SAM file from a DC took about a month to crack so you should rotate passwords on a frequency that beats that race. But it's always struck me as an awful lot of burden to put on to your users for a rather low likelihood attack surface. These days though it makes even less sense.
I have referenced Microsoft's guidance directly when answering enterprise security questionnaires that insisted my company provide this functionality.
We offered MFA instead including Fido 2. If password rotation is that important, you're welcome to pay for SAML support so that you can control it yourself, but the platform would not be offering it.
I think that mandatory password changing only weakens security because it incentivises users to rotate a single fragment at the end of an otherwise static password.
Example:
MyStaticPassword-2019
MyStaticPassword-2020
MyStaticPassword-2021
If an attacker knows that the last 4 characters of a password are "2021" then it is additional information which can help to possibly crack a cryptographic algorithm.
My network login has become progressively simpler as I have been forced to change it. I use KeePass and unique/random 20 character passwords for every website that I log in to. But not for work. It used to be "Quite hard and very long password". Now it's "NotVeryHardPassword7".
Yup, I'd use whatever super-duper random stream of consciousness my password manager cares to emit where it not for the fact that I have to change it regularly. I'd let the password manager handle the logins if the Windows GINA (or whatever it's called these days) didn't require me to type the whole thing. But if I ever have to type the password somewhere, then MyPassword12! it shall be rather than something that looks like line noise because I'm not muscle-memorizing a new 30 char password every 90 days.
You only have to change it once a year? Such luxury. I have to divide by four to figure out how many years I've worked here. Thing is, when the topic comes up it seems that everyone on my team openly admits to doing just that (static PWD with incrementing integers on the end). But they didn't hire me to secure their network, so if no one else cares...
The usual answer to that is to dictate a minimum difference policy between credentials (meaning you have to provide the previous password at the point of change as it can't be read from elsewhere if properly stored, but that is usually the case as a check against someone changing passwords using a session that is accidentally left unlocked). That can lead to passwords-on-paper which is an issue itself, though not a high risk if security against remote attackers is your only significant threat profile.
yup. Even password managers half the time fail to properly capture a password change so that the easiest way is simply to increment the password, then add that increment in the password manager - instead of going through the trouble of generating a new random password which may or may not end up getting saved.
Just had to do a mandatory change. We were acquired so my computer is not fully integrated. To change the password I only needed to provide the code from the Authenticator app (MFA) Whenever I log in I need the password and the MFA code, but if the MFA code is enough to change the pw, what’s the point?
My employer finally got rid of mandatory password changes - mostly. My Surface requires a password change every 30 days in order to log in. Logging in to teach a class that starts in one minute? Guess what. You're going to come up with a new password on the spot or you're not teaching.
In some cases it can make sense, one off the top of my head is captured but uncracked NTLM credentials - rotating the password (even if it’s +1) invalidates the existing hash. There’s probably better ways of doing it technically (resalting the password) but they’re not technically possible.
hese days the only sane way to operate is with password managers and separate 2fa. One single strong password that is only used for accessing the password database. One secure device with the 2fa generation.
From there every site can use a long randomized password. With 16 random characters, pure alphanumeric is more than fine sufficient to be essentially impossible to crack. If one does get compromised, such as by being stored in plaintext, nothing else is. The only way to compromise the user is to compromise the password manager key which should never leave the user's computer.
Yes it does become a master key, but email already acts like that and a well implemented password manager is far better. The alternatives all involve bad passwords, password re-use, and passwords on post-its.
One place I worked at had a policy that you couldn't use any password within your 10 most recent passwords. So when it came time to change they would do 10 password resets in succession so that they could use their original password and never have to remember a new one.
My router had a random pre-generated password. It was a series of consonant vowel consonant atoms separated by numbers. That manages to be reasonably memorable and highly secure, and it's reasonably unlikely to land on something someone finds offensive.
In my first job, the ancient VMS system for timesheets required you to select a password out of a list. You could refresh it as many times as you wanted, but you had to type one of the passwords provided by the system.
It's not just Microsoft, I believe NIST has the same guidelines now.
Forcing people to constantly change passwords just means they either iterate a number or write them down. It also means they start to resent the tech and people who make them do it. It helps no one.
One of the key features to making this work is the attack protection features these services have. Okta, Azure, Auth0 all have this. Is there an open source alternative? Seems like we would need a service, like SPAMCOP is for email, to make it work.
I'm pretty sure at least one of my employers continues to mandate passwords expiration date because of a contract, either with the government or under government regulation, and the regulations are outdated.
Question: If I change my password from mydumbphrase to mydumbphrase1 and the system says "too close to your previous password" is that proof they kept my password in plaintext and that their service in insecure?
My employer has this, but the password change form requires you to also input your previous password so that's how they do it without saving your plaintext passwords.
I'm sorry, but Prof. Falken never would have chosen "JOSHUA" to secure what is essentially the most important computer in all of DARPA/CIA/NSA, etc. that was connected to a landline.
This is also NIST’s guidance. The problem is that PCI requires it pretty explicitly, so if your company requires PCI compliance then you have to convince your auditor to give you an exception.
Turning off mandatory rotation without strengthening other controls would simply allow users to keep their weak password (Spring2021! or {CompanyName}2021!) for a longer period of time.
Ok, but if you're using a password manager with long random passwords, that changes the calculation. The advantage might not be huge at the end of the day, but it's non-zero.
I think it would be good to have mandatory password changing when it is discovered that you have reused a password. Password reuse is a major security breach waiting to happen.
The ideal solution is passwordless multi factor authentication. You have to the power of randomly generated numbers coupled with extreme usabilty. We do that by scanning an encrypted barcode to login with mfa running in the background. We also can do that with a push login approval, or webauthn or FIDO U2F physical keys.
Disclaimer: worked on the design of the passwordless mfa solution set at saas pass.
You still the need the “what you are” or “what you know” to unlock the mobile token. In addition you can also ask for more as step up additional authentication matters under access control policies.
> Researchers have increasingly come to the consensus that the best passwords are at least 11 characters long, randomly generated, and made up of upper- and lower-case letters, symbols (such as a %, *, or >), and numbers.
Microsoft is correct. You can just use the most recent windows 10 zero day and get anything you want, no password or account needed... Or any of the other numerous MS products that currently have zero day vulns.
I still say we should move into the direction of doing away with user passwords altogether and viewing the device itself as the basis for authentication.
Everyone has a personal computing device in 2021. Who is still sharing a family computer and needs to switch user accounts? How many businesses still operate with shared workstations?
Adding additional sessions (i.e. devices) to my netflix account should be as simple as scanning a QR code from an already-authenticated device with my unauthenticated device. This pattern feels magical with applications like Whatsapp web interface. It instantly works and you had to remember nothing. Virtually everything along the consumer segment could work like this.
There are obviously pedantic edge cases that we could invent all day, but there are also blindingly-obvious value paths we can go down as well. Recovery of lost devices is clearly a big issue with this scheme, but its the same resolution in any scenario. You resort to SMS/Email/Phone to re-establish your identity on the new device and use some emergency token issued as part of recovery to bootstrap the whole thing again. It's exactly the same shape problem as forgetting your password.
What happens when one of the "personal" devices gets lost? How do you authenticate to the device in the first place?
I also don't feel like lugging around my employer's laptop wherever I go, but I sometimes happen to need to check an email or something when I'm at a friend's house (so I can't register the device). Should I not be able to do that?
> Who is still sharing a family computer and needs to switch user accounts?
My client does. People work in shifts, it would make absolutely no financial sense to have double the number of computers. It would also be a pain to have to switch screens, etc. Or much more expensive to equip everyone with laptops.
> What happens when one of the "personal" devices gets lost? How do you authenticate to the device in the first place?
The device you initially register on is the one that has access. Subsequent devices could chain off of that one.
If you lose a single device and have others on the same account, it's trivial to recover. If you lose all devices on the account, it's the same scenario as forgetting your gmail password. You go to some recovery page and follow steps to prove your identity again.
I've got this point, this allows you to maintain access to your accounts.
But the question was more along the lines of: how do you protect the lost device from being used by the thief, thereby impersonating you? You presumably need some method to let the device know it's really you.
So if it's not a password, what is it? I seem to remember an article a few years back of a group (probably the CCC, but I'm not sure) that managed to reproduce Angela Merkel's fingerprint without physical access to her fingers. Apple claims Face ID is more secure. But is it, really? I honestly don't know, and finger unlock was supposed to be secure, too. What happens if we find out it isn't?
> You presumably need some method to let the device know it's really you.
Enter literally every mobile device unlock/security scheme since this all began.
Which is more secure in the average case today?
A) A password or passphrase, with all of its historical flaws in aggregate.
B) Apple's iOS unlock feature using a recommended/default configuration, and some 256 bit session token tucked away somewhere in secure device storage.
I would personally have a hard time answering this directly. Lots of "it depends", which tells me there are contexts where each scheme can make sense.
If you were to apply the spy movie aesthetic here, you would probably find it much easier to coax a password out of an unwilling participant than it would be to hack open a pile of cryptographic secrets you found laying on the street.
You do realize that B is just something on top of A, and not instead of A, right?
The finger unlock of my iPhone doesn't let me do everything. There are operations for which the password is required even if you have the right fingerprint.
So basically, the "security" of my phone is protected by my password.
If I know the password, but I don't have the fingerprint: I don't care, I can do anything. I can even enroll the finger I have.
If I have the finger but forget the password, I'm going to have a bad day since the touch ID feature requires me to input my password at least once a week and I cannot change the password or do any other sensitive operation.
So how does this scheme replace passwords? Sure, it's more convenient, since people don't have to type the password 500 times a day.
But will they actually use strong passwords? When I've initially set up my iPhone it asked to set up a code in addition to the fingerprint. That default was a 4 digit pin[0]. That's some high security right there.
---
[0] This was some 4-5 years ago, things may have changed. I remember seeing an article grilling Apple over this default. It was fairly easy to switch to a regular password, but we're talking about the default here, which we know is what most non-technical people will use.
As to what works in practice, most cryptocurrency exchange accounts, which are prime hacking targets as you can steal large amounts of money irreversibly work as follows:
Enter email@address.com and easypassword1
You are then asked for Google Authenticator code, which is a six digit code based on a secret key and the time of day.
It generally works quite well though it's a pain if you lose your Authenticator key (stored the in a phone app usually)
>Password expiration policies do more harm than good, because these policies drive users to very predictable passwords composed of sequential words and numbers which are closely related to each other (that is, the next password can be predicted based on the previous password). Password change offers no containment benefits cyber criminals almost always use credentials as soon as they compromise them.
>Mandated password changes are a long-standing security practice, but current research strongly indicates that password expiration has a negative effect. Experiments have shown that users do not choose a new independent password; rather, they choose an update of the old one. There is evidence to suggest that users who are required to change their passwords frequently select weaker passwords to begin with and then change them in predictable ways that attackers can guess easily.
>One study at the University of North Carolina found that 17% of new passwords could be guessed given the old one in at most 5 tries, and almost 50% in a few seconds of un-throttled guessing. Furthermore, cyber criminals generally exploit stolen passwords immediately.
[1]https://www.microsoft.com/en-us/research/wp-content/uploads/...