Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Frequent Password Changes Is a Bad Security Idea

schneier.com

Post reply on HN
Print view View original

51–59 of 59 posts

Re: Frequent Password Changes Is a Bad Security Idea

#51

Post by jjnoakes »

koolba wrote: post #50
jjnoakes wrote: post #46

Earlier quoted context omitted.

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.

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

Re: Frequent Password Changes Is a Bad Security Idea

#52

Post by mchahn »

bambax wrote: post #14

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

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

Re: Frequent Password Changes Is a Bad Security Idea

#54

Post by koolba »

jjnoakes wrote: post #51
koolba wrote: post #50

Earlier quoted context omitted.

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.

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

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

Re: Frequent Password Changes Is a Bad Security Idea

#55

Post by jjnoakes »

koolba wrote: post #54
jjnoakes wrote: post #51

Earlier quoted context omitted.

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

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

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.

Re: Frequent Password Changes Is a Bad Security Idea

#56

Post by koolba »

jjnoakes wrote: post #55
koolba wrote: post #54

Earlier quoted context omitted.

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

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.

Re: Frequent Password Changes Is a Bad Security Idea

#57

Post by jjnoakes »

koolba wrote: post #56
jjnoakes wrote: post #55

Earlier quoted context omitted.

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 th…

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

Re: Frequent Password Changes Is a Bad Security Idea

#58

Post by koolba »

jjnoakes wrote: post #57
koolba wrote: post #56

Earlier quoted context omitted.

> 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 th…

> 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…

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

Re: Frequent Password Changes Is a Bad Security Idea

#59

Post by cafard »

joeskyyy wrote: post #7

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!

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.

Post reply on HN