Hacker News Reader

Comment by joshvm | Hacker News Reader

We had a gem at my last university (UCL): you must rotate your password every few months, your password can't be anything like any of the previous ones (i.e. previous ones are stored, and they're not hashed), your password must contain special characters etc.

Except.. it can only be 8 characters long. Anything else gets truncated (they explicitly said so). The mind boggles.

I have no idea where this limitation comes from, do people just set an 8 character field in their database? Was this a problem decades ago that they figured they'd save a few megabytes of storage space?

I think they've finally changed it so that the reset period is determined on your password complexity, no length limitations, and you can have 2FA (or at least mobile password reset).

View on HN

> your password can't be anything like any of the previous ones (i.e. they're not stored hashed)

That's... not necessarily the case. You can implement that check by only storing hashes of previous passwords, or of patterns derived form them that are also forbidden (e.g. store a bcrypt of every previous password converted to all lowercase and with numbers and symbols removed).

Manager: We need to ensure people aren't using similar passwords on reset, but we can't store the password unhashed.

Developer: Similar passwords? Or Same passwords. Similar is hard.

M: Similar. Can't let people be lazy with their passwords.

D: Well, if we really have to do it, I guess we could store a bunch of hashed variations of the password, but...

M: Good! Let's do that.

D: ...but that could be a massive amount of space for long passwords.

M: Okay, we'll just enforce short passwords then.

D: ...doesn't that more than negate all the benefit of preventing similar passwords when rotating them?

M: Doesn't matter, the CEO said he wants this. Hop to it!

Developer laments the stupidity of their life

It's funny because "DecemberSixteen" is very different from "MarchSeventeen" as a password from a characters point of view but is trivial to extrapolate if you know the guy has to change password every 3 months.

Why would they need to store the hash for all the combinations?

Why not generate a list of similar passwords to the new password, hash them all using the same salt of the previous password and then compare them.

Depending on what is considered "similar", every extra password character may exponentially increase the number of similar passwords.

Well in my case, there was only an 8 character limit, so there was a least a bound on it. I didn't investigate how far you could deviate from an old password before it was allowed though.

Been there, fought that.

longer passwords don't hash to longer values (within any reasonable variation of order of magnitude in input size). That would defeat the purpose of hashing

But a longer password would require more combinations for similarity than a short password.

Ah. Thanks for clarifying.

Still, permutations longer hashes don't require substantially more space. Password storage is a completely trivial fraction of total storage -- Compare to a single photo, or a video!

And further still, they don't need to _store_ all the hash variations

https://security.stackexchange.com/questions/53481/does-face...

Wow, it slipped my mind entirely that you could do the permutations when you create the new password but before verifying, rather than after creating a password. That's a great idea, and embarrassingly obvious in retrospect.

Yes, that's the point being made.

Though I'm pretty sure I've seen "Your password is too similar to a previous password" before, which suggests some kind of plaintext Levenshtein distance check.

"Is the same as" can be fine with a hash, but "Is too similar" is definitely a red flag.

When I've seen that "your password is too similar..." warning, it was with a system that required entering my current password to set a new password, so no need to store a previous version in plaintext.

Though another way around it is to apply a set of common transformations to your new password, hash it and see if it matches the previous one. I.e. if your current password is "Password123" and you try to set it to "Password1234", the system could truncate the last digit on the new password and see if it matches the current one.

I think almost every system requires you to put in your current password to change new password.

Aren't passwords hashed on the client side before sending it across the network? That would make your way around not work (unless that's done on the client side also after verifying from the server that it's correct).

Hashing it on the client side will make the hash the password. So the stored hash can be used as password by turning off the client side hashing, for instance by turning off javascript. You use https to avoid sending the password in cleartext over the network

I've certainly never encountered a web app that hashes locally before sending. I suppose it could work if this was at the account creation or password management stages, but you couldn't implement it at the login stage for obvious reasons.

I'm having trouble imagining what scenario client-side hashing would protect against.

Man in the middle attacks fetching for plaintext passwords

-- edit: using a KDF would improve it even more.

If the client only sends the hash to the server, a MitM also only needs to capture the hash.

Sure, but if they've MITM:ed your trusted certs, aren't you already boned in so many ways?

That's unnecessarily complex. Just ask for the old password when doing an expiration reset. Validate the old one then compare that against the proposed new one.

Actually, that's a very good point - you did indeed have to submit the old and new passwords. I want to say that they checked against older passwords too, but I might be misremembering.

That doesn't help. Your new password might be the same as the twice-previous password.

You're certainly right (e.g. that's how Facebook can remember so many different variations of you password without storing the actual password itself), but if their engineers are capping the password field at 8 chars, I HIGHLY DOUBT that is what's going on.

If you really want to annoy me, use soundex[1] as a final normalization step.

[1] https://en.wikipedia.org/wiki/Soundex

Doesn't that decrease the benefit of storing a hash? You probably know the process through which the derivative hashes are generated, which is not known-plaintext but seems kinda iffy still.

I think it would decrease the benefit, yes.

If you store the hash of the password, plus the hash of a hundred "similar" passwords, then the hacker only has to brute-force one to find that they are on the right track, and then brute-force "similar" combinations.

Unless you do it the other way around: Generate a list of all passwords similar to the one the user just entered and see if that matches any previous hashes. This is how Facebook's password check works [0]

[0] https://security.stackexchange.com/a/53483

Supposedly, you'd only be able to get feedback about the similarity of a password in a state where you're already authenticated. So I guess this would help an attacker get the password when they've already gained access in some other way. But that's a big assumption.

Yeah, they probably stored old hashes, but I find it hard to believe they stored variations of old ones as well. Maybe they did though!

I guess it comes from old UNIX passwords (80s and before). They were limited to 8 characters if my memory doesn't fail me. But they were already stored with one way encryption.

Your memory's fine.

man 3 crypt => https://linux.die.net/man/3/crypt

Thanks.

That prompted me to google up a summary of the password length limits of various operating systems https://security.stackexchange.com/questions/22721/password-...

I have seen my online password for Australia's biggest Telco, in plaintext on a computer screen in the shop while buying a new phone...

My University also had an 8 character restriction. When I asked them about it, they said it was because they wanted a single password across all of the systems, and some of them were really old and had an 8 character restriction, so that had to propagate up to everything else.

I once had similar problem in some ancient LDAP installation and it turned out that adding random 9th character was enough to pass the check while keeping the password effectively the same :)

Theoretically, using homomorphic encryption you can both store passwords securely and check them for similarity. :)

If the similarity of ciphertexts reveals information about the similarity of the cleartexts, then given you have the encrypted password and the encryption algorithm, couldn't you guess the cleartext password by performing search? The point about hashes is that nobody can decrypt, although everybody knows the "encryption" algorithm. So not sure that homomorphic encryption would help in this case. Or am I missing something?

Comparing the hash values would also work (if done right, hash collisions are extremely rare).

I worked at a bank that still has online banking password requirement of 6 characters... though must contain a number so totally secure.

Internally they still use Lotus notes 7.? last I heard. And storage limit was something like 100Mb if I recall correctly.

Britain and the Commonwealth feel especially bad with onerous and arbitrary requirements on passwords and such.

The most odd bit about that UCL password policy is that it said "your password change has been submitted and may take up to 24 hours to take effect." To this day I'm not sure if they were just displayed in cleartext and someone just typed them in by hand

I think some SSO systems actually have to sync the password up with all the crappy computer systems that use it (rather than using actual SSO) and that syncing is done on a cron job at 3am.

Reply on news.ycombinator.com