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.
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...
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.
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.
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.
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.
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.
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:
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.
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".
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.
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)
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.
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.
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.
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
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 :/
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.
> 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.
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.)
> 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.
> 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.
> 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.
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
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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?
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.).
> 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.
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.
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.
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)
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.
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.
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).
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.
>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.
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).
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.
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
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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. :<
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.
I am forced by management goons to give human resources database password in plaintext to indian/chinese developers who cannot grok typing a password but their job is sweet and better than mine but whites cant do database work dont be silly. Dont worry hr data isnt institutional only the poor suckers who work here are at risk.
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.
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
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.
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.
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.
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.
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 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.
> 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 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.
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?
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.
> 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.
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...
> 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.
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.
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.
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.
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.
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.
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?
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.
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.
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:
> 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)
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.
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.
> 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.)
> 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.
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!)
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.
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.
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.
> 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.
> 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.
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?
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.
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.
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.
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.
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 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.
> 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.
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.
> 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.
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.
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.
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.
436 comments
[ 4.8 ms ] story [ 351 ms ] threadExample:
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.
I maintain a user-facing system that expires passwords after 120 days, no exceptions, and I've tried in vain to get that restriction lifted.
Nothing worse than users blabbing details about their passwords like that.
The big obstacle to reason is baked-in policies encouraged or enforced by regulation which demand rotation.
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.
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 yeah, if you think using your org domain to authenticate people on a 3rd party cloud server is a security problem, well you are not alone.
https://docs.microsoft.com/en-us/microsoft-365/admin/manage/...
Which states:
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.
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.
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.
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.
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?
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.
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.
85% of Americans have a smartphone. 15% of Americans do not. https://www.pewresearch.org/internet/fact-sheet/mobile/
What are the stats for other countries?
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)
The ones that deal with physical objects. Ones that control machinery, keep track of objects in warehouses and stores, etc.
We were required to change passwords once a month, and not re-use any of our last 6 passwords.
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.
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.
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.
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.
Because it had a fairly short password cycle, I'm sure most users ended up with something like "password1!TwentyFour" then "password1!TwentyFive".
Me: I just changed my password 51 times when it was time. I'm not sure what point I was proving, but I was proud of myself.
Of course, it's also possible they stored the clear text password, I have no real way of knowing.
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.)
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.
SomePasswordABC SomePasswordDEF SomePasswordGHI
...
Or
My1Password! My2Password! My3Password!
...
Or
MyPasswordUno MyPasswordDue MyPasswordTre
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.
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.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
/s
> 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.
These are contradictory statements.
Then the system could reject these on the next password change without storage of the original plaintext password.
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 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 think the idea is that most users will just choose another password if you tell them the one they entered is too similar to their previous password.
But my opinion is that ensuring creative passwords with an unclear similarity rule will only result in creative bypasses of that rule.
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.
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.
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.
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.
it's the latter, not the former. once you're compromised, passwords, changed or not, are no longer an obstacle at all.
password rotation does not increase security.
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.
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.
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.
https://inbox.vuxu.org/tuhs/87bluxpqy0.fsf@vuxu.org/
https://fossbytes.com/unix-co-founder-ken-thompsons-bsd-pass...
[1] https://github.com/dspinellis/unix-history-repo/tree/BSD-3-S...
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?
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.
The focus should be on preventing a security breach, not what to do after its happened.
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.
https://pages.nist.gov/800-63-FAQ/#q-b05
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.
Disclaimer: worked on the design of the passwordless mfa solution set at saas pass.
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.
>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/...
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.
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.
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.
Would love to know how long it would take to crack
5ae2b1ce4999dfd2c8f1a57509650e75
as a password.
Hell even 5ae2b1ce4999dfd2 is probably more secure than the majority of passwords chosen by users
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…
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.
You can do the same with your Microsoft account: https://www.microsoft.com/en-us/microsoft-365/blog/2018/11/2...
The big name left out of all this is Google. They seem to have embraced using passwords everywhere, except, oddly enough, on their passwords management website - https://security.googleblog.com/2019/08/making-authenticatio...
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.
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.
If your fingerprint is compromised, where can get new fingerprints?
Device based security (like a FIDO2 key, or even a phone with an authenticator app) is great, beuacse when it's compromised, you can change it.
Biometrics though is even worse than a userID, it's public, left everywhere, and can't be changed
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.
I'd point out that a password can also be compromised. https://xkcd.com/538/
https://twitter.com/jmgosney/status/714599256410054657
But given a list of common words, it’s pretty easy to figure out how “Autumn2012!!!” will change with the seasons.
[1] https://google.com/search?q=0x5ae2b1ce4999dfd2c8f1a57509650e...
[2] https://google.com/search?q=0x5ae2b1ce4999dfd2+%2F+%28170+qu...
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.
I agree about incorporating other characters. As long as it's not "Dictionaryword1!" :) https://youtu.be/aHaBH4LqGsI
5ae2b1ce4999dfd2 is about 10^19 options.
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.
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.
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.
https://www.yubico.com/products/computer-login-tools/
Also I can use it for various other things (like password manager secret etc) which don't support yubis out of the box.
rips hair out
https://www.ncsc.gov.uk/collection/passwords/updating-your-a...
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.
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.
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.
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!
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.
Also, use of the term "passphrase" instead of "password" and recommending a short sentence with multiple words, casing, spacing and punctuation.
Not plaintext, but encrypted (not hashed) with the idea that they can be used for things like that.
https://docs.microsoft.com/en-us/windows/security/threat-pro...
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.
Assuming the user uses the password in other places, this can be a bad thing.
This is selfish, though. If that database of passwords leaks, they are prime candidates to test on *other* sites.
1. https://www.systutorials.com/docs/linux/man/8-pam_pwquality/
correct, you do it like that:
- h@se2003 - h@se2006 - h@se2009 - h@se2012 - h@se2103 - h@se2106
you get the point ;-) bonus points for encoding the username into it and making it a thing for the whole company, yeah very secure!
Sup3rdup3rp4ss2021Q2
One of the reasons why I want the Credit card cartels to die.
More cynically: password reuse is allowed after 5 cycles.
This way, you can't change your password more than once a day. This makes quickly cycling through to get back to your original password hard.
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.
Unless you had data on your smartphone or had a friend who was logged in, you were SoL.
It's why mandatory change policies are so stupid. Users will always sacrifice security for convenience.
Even those that know better.
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).
It's orders of magnitude less of a pain in the ass than password cycling.
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.
https://gist.github.com/technion/65c652194fb1427e6828ea23ff4...
forcing https://www.washingtonpost.com/news/the-switch/wp/2016/03/02...
regular https://www.wired.com/2016/03/want-safer-passwords-dont-chan...
password https://practical365.com/security/microsoft-recommending-non...
changes https://www.scmagazineuk.com/end-password-expiry/article/147...
is https://www.sans.org/security-awareness-training/blog/time-p...
a https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-r...
bad https://arstechnica.com/information-technology/2016/08/frequ...
idea https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-r...
can https://www.schneier.com/blog/archives/2016/08/frequent_pass...
you https://cryptosmith.com/password-sanity/exp-harmful/
please https://www.zdnet.com/article/changing-your-password-regular...
stop https://www.ncsc.gov.uk/articles/problems-forcing-regular-pa...
this was one of the more cheeky version I sent to a vendor.
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.
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.
I wonder if Microsoft employees (all or portions) have to rotate their passwords due to PCI compliance despite Microsoft's stance on the subject.
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.
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.
Attackers don't need hints on passwords, they don't need hints on targets. They just target everyone, and try all easy passwords.
Pentester here, to clear any dubious assumptions.
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.
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.
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.
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".
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.
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.
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 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.
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.
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.
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.
I simply disabled password rotation policy on my account ノ(ジ)ー'
https://github.com/MicrosoftDocs/windows-itpro-docs/issues/5...
Password rotation has always been a bad idea.
https://labs.bishopfox.com/industry-blog/2018/08/password-se...
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.
After that, the advice sounds pretty correct to me.
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)
- 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.
[0]: https://zalberico.com/essay/2020/06/13/zoom-in-china.html
> 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.
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...
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.
Heh...
Developer: Shoot, we've got an off by one error here. No problem, I'll just add one. Or should I subtract one?
*10 min later*
OP: That's weird, my 30 character password is now failing.
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.
(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.)
And they add the horrible on-screen pad you have to click through (everyone can memorize it).
People working in bank regulations are truly incompetent.
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 use Fidelity now and while it has issues, it's much better.
Still can't believe they were allowed to have such a bad and secret password policy for so long.
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.
[1] https://www.ing.com.au/securebanking/
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.
For pw manger based passwords sure you just cut your search space down by a lot but for human typed passwords that are words / sentences ehhh
Though it's a little bit different when it's an intentional tradeoff decision vs. just being bad at software.
In FB's case with billions of non-technical users the tradeoff is probably valid.
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?
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.
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.
Easier just to phish people.
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.
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've heard that the reason is interaction with legacy systems.
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.
More info on this, since I'm no expert: https://security.stackexchange.com/questions/39849/does-bcry...
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.
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.
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.
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.
1. https://news.ycombinator.com/item?id=26866624
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.
Woah that's so secure. What if you only had 2 characters; both symbols. I'm sure that is 2x as secure.
Wouldn't it be 4x? (2^2)
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.
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.
* Password managers
* Physical objects that hold the key (credit cards, access cards)
Or, for a non-solution:
* Just get angry at anyone who forgets their password, while also insisting they never write it down (a common approach in the bad old days)
Are there any that encode generated passwords on a slip of paper that require something you know in case you lose it?