Modern GPU based crackers can guess at at a rate on order of about a billion guesses per second. Because password cracking is embarrassingly parallel, a 1000 GPU cluster can guess somewhere in the trillion guesses per second range. This means brute forcing short passwords is now trivial and has caused the increase in length requirements.
My password hates:
Sites that demand you create a login to buy stuff
Trivial sites demanding onerous passwords. Thereby diminishing my feeble brains pool of good passwords for important stuff.
Work passwords having to be changed periodically. The only explanation i can think of
seems to be that the other end of things isnt secure. In which case fix that you dolts.
And it doesn’t even fix that problem. If someone gets ahold of my password, it’s not going to take them six weeks to do major damage. It’s going to take them six minutes, tops, and more like six milliseconds if they’re doing the attack in a systematic way.
The absolute worst is when they not only make you change it, but also require that it not be “too similar” to your previous password (or previous ten passwords, even). Because now, not only is it even harder to come up with passwords, but that’s also proof that they’re storing the passwords in the clear. A password stored in the clear is, effectively, no password at all: It’s like carving “Speak friend and enter” on the front of your server.
I don’t see how a “not too similar” requirement" is proof that previous passwords are stored in the clear.
How else could you compare the old vs the new?
Maybe some kind of limited brute-force guessing of all possible “very similar” passwords? E.g. change, add, or delete one character from the new password, hash the result, and see if it matches the old password hash. That would only require a few thousand guesses, which seems like it’s in the realm of feasibility.
How about changing some of the letters in your easy-to-remember phrase to numbers or characters, so
“eatinggooberpeas” becomes
3at!nggo0berpe@$
That’s not how hash function outputs look. He’s right, most practical hash functions, changing just 1 bit of the input changes the output hugely. They have to either be storing the password in the clear or information about the original password for this similarity check.
Right, I understand that. Here’s what I imagined:
Let’s say the new password is “password5”. To check whether it is similar to the old password, the server hashes “passworda”, “passwordb”, “passwordc” … “password3”, “password4”, etc. If the hashes of any of those matches the old hash, the new password is too similar.
The server needs to temporarily know the new password, and retain the old password hash (which it had to do anyway, right?)
For a limited definition of “similar”, it wouldn’t be too hard to enumerate and test every possible simple change. For the sake of this example, let’s say there are just 36 lower-case letters and numbers and had an 8-character password. You’d only need to check 8 deletions, 835=280 single-character changes, and 936=324 insertions of new characters. Testing that requires less than a thousand hashes, per user, per year (or however often passwords need to be updated).
That’s just it, it will not match, ever. Good hashes, the probability of any 2 strings colliding is very small.
I’m either being unclear or I completely misunderstand the process. Both are always possible 
Here’s what I imagine, in more detail. For this example I’ll just use MD5 (even though it’s terrible for passwords) and ignore salting.
Old hash:
218dd27aebeccecae69ad8408d9a36bf
New password:
password5
The server takes the new password, which was just given to it in plain-text, and generates a list of “similar” passwords with their hashes:
password1 7c6a180b36896a0a8c02787eeafb0e4c
password2 6cb75f652a9b52798eb6cf2201057c73
password3 819b0643d6b89dc9b579fdfc9094f28e
password4 34cc93ece0ba9e3f6f235d4af979b16c
password6 218dd27aebeccecae69ad8408d9a36bf
password7 00cdb7bb942cf6b290ceb97d6aca64a3
password8 b25ef06be3b6948c0bc431da46c2c738
password9 5d69dd95ac183c9643780ed7027d128a
etc.
Clearly, password6 was the old password.
You’re missing the point. He is not suggesting that two strings that are similar in the clear would be similar when hashed. He is suggesting that the hash of the old password be compared with the hashes of trivial variations of the new password. If there is a match then you know (to an extremely high probability) that the user has made a trivial modification to the old password. You don’t need to decrypt the old password (and it doesn’t even need to be possible to decrypt the old password) to do that.
Indeed. And this is from a few years ago.
Store it encrypted. Decrypt. Compare. If too similar, return “Too similar”. Clearly I’m missing something.
No, he’s right, you could do that… If you wanted your login server to run thousands of hashes every time anyone created a new password. It’s not depending on collisions; it’s basically doing the same thing an attacker would do, on a smaller scale. Except that most of them have a loose enough definition of “similar” that it’d take far too long to actually do it this way.
The attackers check that, too. It’s not too hard, especially if you use look-alike characters like 3 for E, ! for i, 0 for o, and so on. Some bloggers have gotten ahold of leaked password files and the tools that crackers use, and passwords like that fall after about three hours, on a single desktop running the attack.
This is not as secure as not storing the passwords. The whole reason for all of this hash business is to not store the passwords at all.
Oops, didn’t realize there was another page, there.
You could do that, if you’re using a reversible form of encryption. But using a reversible form of encryption for your password file is nearly as bad as leaving it in the clear, because users who have not yet logged in need to interact with that file. You could, in principle, secure a setup like this, but it would add a lot of complication, and thus a lot of chances to get things wrong. And any programmer or administrator who is naive enough to think forcing password changes offers any benefit at all is almost guaranteed to get something wrong with a system that complex.
Actually, that’s a terrible idea.
One of our work systems has a feature like that. There’s a list of verboten words or chunks of words. If you try to include one of those, your password choice is rejected.
But the list is secret. You have no idea what words or 3 letter sequences are on it. So in effect anything but pure gibberish is prohibited, because I (and most users) are not willing to try 15 or 20 times to guess at a rememberable word that isn’t on the list. Which list is ever-growing.
Gawd I hate that.
True. It’s different where the main threat to watch out for is someone with access to your locked desk drawer vs. someone hunting online.
Hundreds of thousands of known passwords have been released on the internet. That means that almost any simple transform that you can remember, is already known to password crackers, just by having examined hundreds of thousands of passwords.
Which is to say, your hypothetical password made from 3 dictionary words is not very strong, and transforming some of E to 3 and I to ! and o to 0 and a to @ and s to $ does not make it strong. It’s still a 3 character password with alternate fonts.
It would be found by any competent password cracker. Still, it puts you a long way in front of most people, they are only going to crack your password after they’ve already cleaned out the people who used “12345678’, 'password”, or “ThelmaLou”, and by then your bank might have already warned you.