Hacker News Reader

Comment by kayodelycaon | Hacker News Reader

I got up to P@ssW0rd12 at one job.

I was working my way to it, when IT rolled out a new policy of "cannot share more than 2 consecutive characters with a previous password" or something like it, included in an email along the lines of "an audit has found this new policy applies to you".

Dicks.

And that's how you ensure everyone writes their password on a sticky note.

Eh, a sticky note is pretty darn secure for the kinds of attacks you care about. If your attack vector is someone breaking into your office the security game changes completely.

Yeah they either need a keycard or some tailgating to get to the bottom of my keyboard at which point they could just take the damn laptop and shuck the drive into an external enclosure and get everything that way, so nbd in my opinion.

> shuck the drive into an external enclosure and get everything that way

Disk encryption (ie, BitLocker) is supposed to prevent that from working.

> If your attack vector is someone breaking into your office the security game changes completely.

There are at least two other important attack vectors against "sticky notes": accidental sharing through photographs and/or online meeting cameras, and visitors memorizing visible passwords. Both are defeated by hiding the sticky note below the keyboard, but my guess is that most people leave it visible on the monitor bezel.

I leave a post it on my monitor with a wrong password as a decoy.

If that policy is enforceable, someone would have to be storing passwords in plaintext, or the hashing algorithm is too weak.

IT shouldn't be able to tell anything about plaintext password similarity beyond equals or not-equals.

I had a similar concern. Or maybe it was a company wide email and that language was in there just because.

Of course, our company-wide email was down for 2-3 months a couple years ago due to a ransomware infection, so our IT isn't stellar. So who knows!

Ad-hoc, this is correct.

But at the time of the password change, no, assuming password changing requires you to enter your current password as well.

If just with previous password, then yeah, that's fine, but more then likely they are saying with the previous N passwords, which would require storing the previous N passwords in some kind of plain text or easily reversible form. Even if those old passwords are useless at that point (which might not be the case for something like a laptop that hasn't talked to the domain controller and learned that the password has been updated or something), it's still dangerous (what if they used that password on a vendor's site, or on their own banking login...)

The password-change form should be using a password field, and that should not be allowing any code or scripts to grab the plaintext stored in it.

If the code that compares your current password to the new password can read the plaintext of your passwords, so too could a malicious program.

Using HTML input type="password" alone is not sufficient protection. The same steps that protect password changes from malicious attackers must necessarily protect them enforcement of bad IT security policy.

The check is done server-side.

At the time of a password change, the server still has your old password hash stored, and in the process of changing it, you are sending both your old password and new password. The server can verify both that your new password and old password differ enough while also verifying that the old password you sent it is valid.

Doesn't that imply that the are saving your previous passwords in plain text somewhere instead of saving hashes of them? How is this more secure?

This would be my guess too. Alternatively, maybe they save hashes of all substrings of length > 2 and check all hashed substrings of the new password against them.

(Which - in my limited understanding of infosec - would be only marginally better than plaintext, but I can be wrong.)

Yeah, having hashes of substrings of a password would help a LOT when brute forcing. If I have a 10 char pass, and I'm storing 1 hash of the full pass + 9 hashes of the 2-char substrings, I can now brute force all those 2-char hashes and then fit them together in the few valid ways they could go together (assuming there is more than 1) until I find the final hash. Salts wouldn't matter.

Usually, when you change your password, you have to enter your old password. With both plaintexts, the check is trivial.

It also means it should be possible to bypass that by changing the password twice or by "forgetting" your old password.

Another possibility is that they simply lie to you and the rule that is actually checked is much more permissive. I've often seen requirements that are not actually checked

Reply on news.ycombinator.com