
Frequent Password Changes Is a Bad Security Idea - alanfranzoni
https://www.schneier.com/blog/archives/2016/08/frequent_passwo.html
======
MAGZine
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:

[https://medium.com/the-lighthouse/how-a-password-changed-
my-...](https://medium.com/the-lighthouse/how-a-password-changed-my-
life-7af5d5f28038#.dlynk50b7)

Previous discussion on it:
[https://news.ycombinator.com/item?id=8015470](https://news.ycombinator.com/item?id=8015470)

~~~
LionRoar
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!" :)

------
petercooper
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.

(Update: I've found a reference to the story at
[https://www.theguardian.com/books/2014/mar/30/do-no-harm-
sto...](https://www.theguardian.com/books/2014/mar/30/do-no-harm-stories-
brain-surgery-review-henry-marsh))

(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.)

------
lips
Does anyone aside from HN type folks listen to these recommendations?

I just had a major banking institution send me a plaintext pw instead of reset
token, with a 15 char limit, and a rotation requirement.

~~~
perlgeek
> 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.

------
dguest
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.

~~~
koolba
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.

------
bambax
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).

~~~
toomanybeersies
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.

------
Theodores
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.

------
0xmohit
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].

[0] [https://www.passwordstore.org/](https://www.passwordstore.org/)

~~~
eitland
Mentioned in the article.

~~~
0xmohit
Happened to see that _after_ posting the comment. So it's probably even more
common!

------
snuxoll
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.

------
koolba
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)._

~~~
jjnoakes
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.

~~~
koolba
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.

~~~
jjnoakes
Like I said, that's all I see. I doubt these systems are backed by LDAP, but
that's irrelevant.

~~~
koolba
Are the authentication backends in-house, FOSS, or off the shelf products?

~~~
jjnoakes
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.

~~~
koolba
> 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.

~~~
jjnoakes
> 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.

~~~
koolba
> 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._

------
hartator
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.

------
jwatte
Tell that to Wells Fargo commercial. 12 character max, change every other
month.

~~~
timmytokyo
If they nave a maximum pw length, they probably have a significant aecurity
issue. Namely, they are likely not storing a hash.

------
barrkel
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.

------
Tempest1981
I would guess that phishing works better than password guessing. Not arguing
for weak passwords, just thinking big picture.

~~~
0xmohit
True.

Unless you have the same password across a dozen sites.

------
angrow
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.

------
ashitlerferad
[https://en.wikipedia.org/wiki/Diceware](https://en.wikipedia.org/wiki/Diceware)

------
tombooth
This is echoed by CESG (part of GCHQ) in their password guidance:
[https://www.cesg.gov.uk/guidance/password-guidance-
simplifyi...](https://www.cesg.gov.uk/guidance/password-guidance-simplifying-
your-approach)

------
joeskyyy
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!

~~~
adrianN
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."

~~~
tbihl
No more than three consecutive letters. That's when things get tedious.

~~~
snuxoll
Entropy? What's that.

------
ukj
To prevent people doing this just throw in a string similarity algorithm into
your password-change UI.

if similarity(old_password,new_password) > 50% then reject password change...

~~~
kwhitefoot
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.

~~~
Sean1708
It could be done on the client if you get them to enter their old and new
passwords.

~~~
tzs
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.

------
paulddraper
The point of changing your password is to counteract any hacked passwords, I
think.

But WHY ARE YOUR PASSWORDS BEING COMPROMISED?

That's what you need to address.

------
steve371
I think password + security tokens is a more common way to go nowadays, when
you need to access externally.

------
dingleberry
how about $ echo "password" | md5sum 286755fad04869ca523320acce0dc6a4

$ echo "Password" | md5sum 29f33cab54c2a8858885b95d8fbb7ff1

$ echo "PAssword" | md5sum 20a68cafb28eb68e306be529a29a8a62

$ echo "PASsword" | md5sum 2ed0aec406faee855f7739bc94fa60d0

------
yeukhon
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.

~~~
Retra
Oh, yeah. They'll never just write it down if you do that.

~~~
abstractbeliefs
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.

