> Does anyone aside from HN type folks listen to these recommendations?
Probably not. But if you work as a contractor for somebody with non-sensical requirements, at least you have some research that you can link to to support your point.
I also hate to have to mandatory change my password. I am paranoid, never used 2 times the same password for somewhat important account and have a mental trick system to remember my password. When asking for a password change, it's fucking it up. Looking at you Linkedin and Paypal. Thansk for crappy security and annoying password policy.
For those who work at corporations with password rotation policies, it may actually be a good way to get creative. This guy changed password rotations into a lifehack:
Thanks for the link, I reread it.
Nice story but I think I can guess his current password now: "Plus, if you’re interested in more of this, I’m writing a book!" :)
I usually just make up a crazy long sentence I'll remember, with no logical order in it. Something funny to me so I'll easily remember it. Throw in some assortment of numbers and symbols. Bam! Works like a charm!
Then the sysadmin hits you with a "at least 8 characters, no more than 13, one uppercase, one lowercase, a number, a special character, but not one that can't be encoded in EBCDIC and the password must differ in at least three places from the last 10 you used."
Ah. Last Friday at work I changed my password. It worked fine when I unlocked my computer after stepping away. On the way home, I noticed that my iPhone wasn't updating email, and recalled that I hadn't changed the password there. But I could not get the iPhone to accept my password. Nor could I get Outlook webmail to accept it. I was afraid that I might have to trouble one of the network admins, but I tried the VPN client. That accepted the password. I RDPed into a machine on the internal network, changed the password to something a little shorter, and confirmed that Exchange was OK with it.
As I recall, the boundary was somewhere around 20 characters.
There is also the matter of cost-benefit analysis of time spent updating passwords. Where I work we have a special code that has to be typed in by logged in members of the team if they want to really delete a transaction, this code is the same for all members of the team. A manager sets this code to expire on a monthly basis because a new code will be good for security, apparently. In reality this means that on the first of each month a team are locked out for an hour or two whilst the new code gets generated and circulated - in email. So there is a misunderstanding on security plus an implementation issue leading to disruption equivalent to the loss of a person's productivity for a day.
A similar scenario of disruption happens if you use lots of devices and need to update a password on several boxes to get working again. There may not be the communication overhead of my special code analogy (which is invariably delayed due to waiting for the manager to get out of meeting), however there is still disruption and time taken out from the task in hand.
As an aside, I like 'ambient' passwords, e.g. the VAT number on the receipt that you got given buying your lunch, the receipt can be kept in the top drawer - safe from the cleaner - and, if it is lost, you can go to the shop again to get another receipt.
It's a double sword. The true issue with frequent password change is people really don't want to be creative. They ended up either changing one letter, or adding an extra letter. At least do a quick distance check and deny password at 90% similarity.
If everyone in the office wrote down their secure password and stored it in a locked desk drawer, that's probably more secure than the entire office using weak passwords.
If nothing else, it means the person has to have physical access and be able to pass off rifling through someones desk after breaking it open.
While this sort of stuff has happened in on-premise pentests, it's certainly not the normal way to attack when it's done for real.
Not news to anyone in the security scene, especially as a 30-90 password lifetime disincentives people from actually creating a complex password so they'll do stuff like Sp0useName02 that technically meets the complexity requirements, but is horrendously insecure.
At a client's who requires frequent password changes, people simply write out their passwords on post it notes that they stick onto their screens. Some security. (That's a bank, by the way).
OTOH, maybe coworkers are more trustworthy than external hackers running cracking tools? Might be true at some companies... (I still hate being forced to change passwords.)
I'd say that for most people, their physical security is stronger than their digital security.
Obviously sticking it on your screen is a terrible idea, but if it's in a drawer (especially a locker one), it's probably not going to get stolen, especially not in a bank.
Feynman used to break into safes (he had a non-evil reason). His main technique was looking for notes in the person's desk with the combination. Everyone thought he was a "safe-cracker".
Does anyone actually have data showing that frequent password changes lead to better security?
Because to me requiring frequent password change seems like the ultimate non-technical management blunder: management wants to say they did something to prevent hacks, so they ask IT to require password changes; IT doesn't want to be blamed so they implement it; users comply with the requirements but can't remember their new password (and don't really care about the company's security in the first place), so they come up with something insecure and keep it somewhere even less secure.
In most cases at best it's neutral and at worst it creates a pre-scheduled phishing opportunity. Alice gets an email saying, "Reminder: Your password will expire needs to be updated" and she cheerfully complies.
I suspect that the requirement of (1) changing the password every n days, (2) new password cannot be the same as previous m passwords (usually, m=10) leads to insecure passwords for most.
I've seen people handle such requirements by creating an initial password, say p@$$w0rd and then appending a digit to it. On any subsequent mandatory password change event, they increment the new password from p@$$w0rd0 to p@$$w0rd1.
Not sure if it leads to anything more secure.
Wish more people started to use GPG based password store such as pass [0].
I usually deal with this by appending the month and year of the change to a secure password. Broken if the secure password is revealed, but no less secure than no rotation policy.
Where I work, we change passwords every 90 days, but every password other than full disk encryption, login and password manager are auto generated by password manager, so this mechanic is less of a concern.
I have worked at a US DoD "secure facility". You can imagine the requirements they imposed on password length, characters, frequency of changing, uniqueness, etc. Perhaps you can also imagine that nearly everyone kept their current password written on a sticky-note somewhere in their desk.
This reminds me of a story I read about the NHS (National Health Service) here in the UK.
Some edict came through that scans had to be stored and accessed digitally. There were numerous teething problems in accessing the system, so a brain surgeon was going nuts running back and forth across the hospital trying to do his work.
A nurse in another department said he could use their consultant's login with the password 'fuckoff'. He ran back to his own desk, no go. So he went back and they said, "Ah, he has to keep changing the password each week so try fuckoff45" because the system had been set up almost a year prior. It didn't work, but after realizing more time had passed, he tried "fuckoff47" and it did the trick(!) Note that the problem here wasn't just the password but that sharing entire logins was/is rife.
(The NHS is full of fun IT-related stories. Another was that due to patient privacy laws, keys to access scans had to be sent under separate transport. So you'd end up with situations where two couriers would be delivering separate USB sticks each to access a single scan.)
How does that work? Or, rather, if that can work the system has even bigger problems because you must be storing the passwords in plain text instead of salted hashes.
If they are going to have a "new not similar to old" policy, it should probably be done on the server rather than the client, because the client is less trustworthy.
A password change dialog needs to be asking for the old password anyway and then verifying that it is correct to protect against people who step away from logged in sessions having their passwords changed by pranksters or worse.
I doubt "new not similar to old" policies actually accomplish much. If they are implemented securely using standard technology they will only be able to check the proposed new password against the current password. That just means that instead of having a sequence of similar passwords, P1, P2, P3, ..., users will have two such sequences interleaved: P1, Q1, P2, Q2, ..., where all the P's are similar and all the Q's are similar but the P's are not similar to the Q's.
There's probably a way to do a similarity check between two passwords given just hashes of the passwords (for instance, using homomorphic encryption), but that kind of thing is more research level than deploy live level, I believe. If/when that becomes practical, then a no similarity policy could go back as far as you are willing to keep old password hashes around without being any less secure than a no reuse policy going back as far.
I've never met anyone in the corporate world that does not suffix a digit to their password that increments with each mandatory password change. Most people start with "foobar"[1] then become "foobar2", "foobar3", etc.
[1]: Or maybe "Foobar" (because you need a capital letter) or "Foobar!" (because you need a capital letter and a non-alphanumeric letter).
I've never met anyone in the corporate world who can do that; all of the important systems I've seen require the new password to be "different enough" from the old. Appending or changing a couple of digits isn't accepted.
Every LDAP password policy I've seen only prevents the previous N passwords (usually 5 or 6), requires some combination of upper case, lower case, and numbers, and possibly some punctuation. I've never seen one that actually compares permutations of your prior passwords to check for a minimum change set.
The backends don't matter. It's the password-changing frontend that has both passwords at change time and makes the call.
This isn't about setting the characteristics of a single password, it's about setting the allowed editing distance between them during a password change.
> The backends don't matter. It's the password-changing frontend that has both passwords at change time and makes the call.
I asked about the backend to see if you know of one that supports more than just the current password. You can assume you have the current one as it's required to confirm your current identity. What you wouldn't have is the plaintext of the prior N passwords (N>1).
A custom backend could save the previous N hashes and either check for exact matches or check permutations against it. I'm just not aware of any off the shelf system that does so.
> This isn't about setting the characteristics of a single password, it's about setting the allowed editing distance between them during a password change.
Sure but I meant across more than just one previous password. In the system you describe if I have "FooBar1" and "BazQuz7" as both being acceptable, I can hop between them endlessly.
> In the system you describe if I have "FooBar1" and "BazQuz7" as both being acceptable, I can hop between them endlessly.
Just about all backends test the previous N passwords, so no, you couldn't.
What the system I describe does not prevent is switching between "FooBarX" and "BazQuxY" where X and Y are changing numbers or characters every time you switch back to them. To prevent that you would need a custom backend, sure.
> What the system I describe does not prevent is switching between "FooBarX" and "BazQuxY" where X and Y are changing numbers or characters every time you switch back to them. To prevent that you would need a custom backend, sure.
Yes that's what I figured. Thanks!
Thinking about the problem a bit, I came up with two possible solutions[1].
The first is to save N prior hashes and brute force the permutations. The main issue with this is that if the CPU cost of the hashing is non-trivial (which you hope it would be) then this will be prohibitively slow (though still feasible for a small number of permutations).
The second is to store the plaintext of the old passwords encrypted using the current password. That way after verifying the current password you can decrypt the old ones and run the permutation checks against those as well. Updating the password would decrypt/encrypt the old passwords with the new password as the key[2].
[1]: If anybody else is following this thread and wants to build this, it's all yours!
[2]: Or more likely the new password would be the seed used to derive a key.
58 comments
[ 6.7 ms ] story [ 139 ms ] threadI just had a major banking institution send me a plaintext pw instead of reset token, with a 15 char limit, and a rotation requirement.
Probably not. But if you work as a contractor for somebody with non-sensical requirements, at least you have some research that you can link to to support your point.
https://medium.com/the-lighthouse/how-a-password-changed-my-...
Previous discussion on it: https://news.ycombinator.com/item?id=8015470
I hope that the passwords thus created emerge from good thoughts and not otherwise.
As I recall, the boundary was somewhere around 20 characters.
A similar scenario of disruption happens if you use lots of devices and need to update a password on several boxes to get working again. There may not be the communication overhead of my special code analogy (which is invariably delayed due to waiting for the manager to get out of meeting), however there is still disruption and time taken out from the task in hand.
As an aside, I like 'ambient' passwords, e.g. the VAT number on the receipt that you got given buying your lunch, the receipt can be kept in the top drawer - safe from the cleaner - and, if it is lost, you can go to the shop again to get another receipt.
If nothing else, it means the person has to have physical access and be able to pass off rifling through someones desk after breaking it open.
While this sort of stuff has happened in on-premise pentests, it's certainly not the normal way to attack when it's done for real.
https://www.schneier.com/blog/archives/2005/06/write_down_yo...
Obviously sticking it on your screen is a terrible idea, but if it's in a drawer (especially a locker one), it's probably not going to get stolen, especially not in a bank.
Unless you have the same password across a dozen sites.
Because to me requiring frequent password change seems like the ultimate non-technical management blunder: management wants to say they did something to prevent hacks, so they ask IT to require password changes; IT doesn't want to be blamed so they implement it; users comply with the requirements but can't remember their new password (and don't really care about the company's security in the first place), so they come up with something insecure and keep it somewhere even less secure.
I've seen people handle such requirements by creating an initial password, say p@$$w0rd and then appending a digit to it. On any subsequent mandatory password change event, they increment the new password from p@$$w0rd0 to p@$$w0rd1.
Not sure if it leads to anything more secure.
Wish more people started to use GPG based password store such as pass [0].
[0] https://www.passwordstore.org/
Where I work, we change passwords every 90 days, but every password other than full disk encryption, login and password manager are auto generated by password manager, so this mechanic is less of a concern.
Some edict came through that scans had to be stored and accessed digitally. There were numerous teething problems in accessing the system, so a brain surgeon was going nuts running back and forth across the hospital trying to do his work.
A nurse in another department said he could use their consultant's login with the password 'fuckoff'. He ran back to his own desk, no go. So he went back and they said, "Ah, he has to keep changing the password each week so try fuckoff45" because the system had been set up almost a year prior. It didn't work, but after realizing more time had passed, he tried "fuckoff47" and it did the trick(!) Note that the problem here wasn't just the password but that sharing entire logins was/is rife.
(Update: I've found a reference to the story at https://www.theguardian.com/books/2014/mar/30/do-no-harm-sto...)
(The NHS is full of fun IT-related stories. Another was that due to patient privacy laws, keys to access scans had to be sent under separate transport. So you'd end up with situations where two couriers would be delivering separate USB sticks each to access a single scan.)
if similarity(old_password,new_password) > 50% then reject password change...
Seriously you cannot invent a password scheme where people can choose passwords that will not be vulnerable to this.
A password change dialog needs to be asking for the old password anyway and then verifying that it is correct to protect against people who step away from logged in sessions having their passwords changed by pranksters or worse.
I doubt "new not similar to old" policies actually accomplish much. If they are implemented securely using standard technology they will only be able to check the proposed new password against the current password. That just means that instead of having a sequence of similar passwords, P1, P2, P3, ..., users will have two such sequences interleaved: P1, Q1, P2, Q2, ..., where all the P's are similar and all the Q's are similar but the P's are not similar to the Q's.
There's probably a way to do a similarity check between two passwords given just hashes of the passwords (for instance, using homomorphic encryption), but that kind of thing is more research level than deploy live level, I believe. If/when that becomes practical, then a no similarity policy could go back as far as you are willing to keep old password hashes around without being any less secure than a no reuse policy going back as far.
[1]: Or maybe "Foobar" (because you need a capital letter) or "Foobar!" (because you need a capital letter and a non-alphanumeric letter).
This isn't about setting the characteristics of a single password, it's about setting the allowed editing distance between them during a password change.
I asked about the backend to see if you know of one that supports more than just the current password. You can assume you have the current one as it's required to confirm your current identity. What you wouldn't have is the plaintext of the prior N passwords (N>1).
A custom backend could save the previous N hashes and either check for exact matches or check permutations against it. I'm just not aware of any off the shelf system that does so.
> This isn't about setting the characteristics of a single password, it's about setting the allowed editing distance between them during a password change.
Sure but I meant across more than just one previous password. In the system you describe if I have "FooBar1" and "BazQuz7" as both being acceptable, I can hop between them endlessly.
Just about all backends test the previous N passwords, so no, you couldn't.
What the system I describe does not prevent is switching between "FooBarX" and "BazQuxY" where X and Y are changing numbers or characters every time you switch back to them. To prevent that you would need a custom backend, sure.
Yes that's what I figured. Thanks!
Thinking about the problem a bit, I came up with two possible solutions[1].
The first is to save N prior hashes and brute force the permutations. The main issue with this is that if the CPU cost of the hashing is non-trivial (which you hope it would be) then this will be prohibitively slow (though still feasible for a small number of permutations).
The second is to store the plaintext of the old passwords encrypted using the current password. That way after verifying the current password you can decrypt the old ones and run the permutation checks against those as well. Updating the password would decrypt/encrypt the old passwords with the new password as the key[2].
[1]: If anybody else is following this thread and wants to build this, it's all yours!
[2]: Or more likely the new password would be the seed used to derive a key.
But WHY ARE YOUR PASSWORDS BEING COMPROMISED?
That's what you need to address.
$ echo "Password" | md5sum 29f33cab54c2a8858885b95d8fbb7ff1
$ echo "PAssword" | md5sum 20a68cafb28eb68e306be529a29a8a62
$ echo "PASsword" | md5sum 2ed0aec406faee855f7739bc94fa60d0