Comment by gregmac | Hacker News Reader

Comment by gregmac | Hacker News Reader

Parent Full thread

Except it doesn't help with that, at all.

Many people use predictable rotations (incrementing number, date appended), so if you know one, you know them all.

Also if they've shared it once, why would they not share it again? Put another way: why is making them regularly reset their password going to make them suddenly follow security protocol, when it didn't the last n times they had to change their password?

If the office thinks it's okay to share their password it's also a symptom of several things:

* Lax security environment, with not enough emphasis on security training and importance.

* Poor senior management. There should be reprimands for violating security rules, as severe as losing your job for repeat offenders, and obviously IT can't do this on their own.

* Bad work environment provided by IT. Why are they sharing passwords to begin with? Maybe the environment is overly locked-down with too many restrictions, or maybe the collaboration tools are just bad or missing.

Fix those, the password sharing stops.

I didn't say it solved all problems. I said it was there to address that issue.

It does help to limit the scope of who has passwords. Certainly not a perfect solution, but it isn't completely ineffective either.

> It does help to limit the scope of who has passwords.

Only if the rotation isn't predictable. If I receive "password3" and it doesn't work and Joe who shared it with me isn't available, I probably wouldn't think twice about trying "password4".

It's trivially solved by comparing new password to all previous passwords and decline if they are similar. And if they wrote their passwords on the stickers, they should be explained that it's not appropriate.

I agree that this approach is not very user-friendly.

I don't think it's trivial to find similar password for multiple reasons.

Comparing old passwords without plaintext is really hard and at best inexact.

Storing them plaintext (or even reversibly encrypted) is completely stupid, of course.

Even if these technical problems could be solved, sequences like: November6, December7, January8 are not "similar" but easily predictable.

Even this sequence is probably not hard to figure out if you look at a keyboard: Secret1 Drvtry2 Ftbytu3

Deeper though, what security threat is this actually mitigating? Bad passwords caused by rotation requirements that are needed because of bad company policies, training and practices? Is there a security equivalent of "yak shaving"?

How would you do the comparison? Wouldn't it require storing all the previous passwords in plaintext?

If only the hash and salted password is stored, as recommended, how would you know that "myOldPassword21" and "myOldPassword22" are similar ?

You make the modifications and store those hashes as well.

Can't have a new 'similar' algo for past pws, obviously.

If you store N variations, a random guess has N chances to hit one. Once an attacker knows a variation, they may be able to use it to narrow down on the real password.

Same way you check if the password is correct. Check against the old hashes. When the user sets the new password, if it looks like it matches an iterative pattern (i.e. if it ends in a number) then test the previous few from that sequence against the old hashes. Note, this is still a terrible idea.

Cryptographic hashes of similar strings can't be similar.

You don't compare the hashes. When the user changes the password to "myOldPassword22", you hash "myOldPassword21" and "myOldPassword20" etc and compare those to the old hashes.

Do you know how many variations there could possibly be??

For example, I could use: myoldpasswordA1 / myoldpasswordB2 / myoldpasswordC3. Probably obvious to a human my next one will be D4, but it is a comparable problem to "play every possible game of chess" for a computer to figure that out.

Combined with using a secure computationally-expensive password storage mechanism (eg: bcrypt or PBKDF2) and I'm not exaggerating: it now takes billions of years to verify a password change is allowed.

And this is trying to solve a compromised password problem. If there's no compromise, rotating passwords is pointless.

If the password IS compromised, rotating the password doesn't really fix it, it merely limits access -- maybe. It doesn't address the original means of the compromise (so you have to assume that's still there). It doesn't address backdoors installed. It doesn't address information stolen.

So this is a hell of a lot of work to accomplish .. basically nothing.

> For example, I could use: myoldpasswordA1 / myoldpasswordB2 / myoldpasswordC3. Probably obvious to a human my next one will be D4, but it is a comparable problem to "play every possible game of chess" for a computer to figure that out.

Two possible changes (forward/backwards) for two characters out of 15. 420 combinations. Not exactly billions.

> Two possible changes (forward/backwards) for two characters out of 15.

Yes, but you can only cut down the sample space in this way because you can look at "myoldpasswordA1" and know that the 'A1' characters are the iterators. A computer doesn't know that.

My figure is for testing all possible ways of changing two characters by one each (and the ways of changing only one character are a tiny subset of that). This doesn't catch people who change 3 or more characters, or who change characters by more than 1, but at that point is it really still so easy to guess?

You're focused on the wrong problem!

Why does someone have an old password in the first place? You should be asking how it got compromised, who knew the credentials, if it was compromised while still active, and if so, how many backdoors were installed, what data/systems were compromised, and how do you prevent this from happening again.

None of the problems could have been avoided if only there was a better password iteration detection algorithm.

> Why does someone have an old password in the first place? You should be asking how it got compromised, who knew the credentials, if it was compromised while still active, and if so, how many backdoors were installed, what data/systems were compromised, and how do you prevent this from happening again.

All true. Nevertheless, there are cases where someone gets a one-off copy of a password - perhaps overheard. If you force them to actively install a backdoor then you increase the costs of attacking greatly. It's not about perfect security, it's about the cost/benefit - a lot of crime is crime of opportunity, especially internal fraud.

> If you force them to actively install a backdoor then you increase the costs of attacking greatly.

I think that it's my fault, but I can't understand this sentence. Doesn't forcing someone to install a backdoor decrease security? The only reading that makes sense to me is "If you make it so that it's user action, rather than inaction, that results in the installation of a backdoor …"?

(For what it's worth, although I disagree with you, I respect your dedication to arguing this determinedly but civilly.)

What I meant was: "if you force an attacker who obtains a one-off copy of a password (perhaps overheard) to actively install a backdoor (in order to have the capability to perform an attack at some later time - as opposed to being able to passively maintain that capability by simply remembering that person's password pattern) then you increase the costs of attacking greatly"

  >> comparable problem to "play every possible game of chess" for a computer to figure that out.

my_password + iterator is a very common password convention.

It would be a poorly programmed computer that didn't consider this possibility.

Reply on news.ycombinator.com