Seems very secure: no one can use your password. They have to be willing to call in every time. Maybe we should just replace passwords by making people call in? Or go somewhere. We could restrict all bank withdrawals to the branch where you opened your account. Hey, I think we are on to something, there…
Assuming the hashing isn’t too expensive you can do this.
Take the password the user entered and try all one-character transforms on it (addition, subtraction, change), hash them and see if it matches the old one. Assuming you confine yourself to the usual English ascii space that’s unlikely to be more than a few thousand tries.
1 Like
There’s an easier way of doing this, just specify a minimum Levenshtein distance between the old and new.
1 Like
You are essentially describing two factor auth.
As to “why have any rules”, I believe @awesomerobot covered this well in his reply above.
@orokusaki I am proposing only one master rule, length … with some bonus server side checks against:
- top 100k known passwords
password1234 - basic level of entropy
aaaaaaaaaa - matching username or email
The last one is indeed a special case, but if my username is “codinghorror” I should not be allowed to have a password that is also “codinghorror”, certainly? Guess you’ll have to try it out a few places to see if I do 
Now, the only question left to answer is – why does every lousy website thinks they are the most important thing in the world and require a complex password?
Like this one here – I would be perfectly fine with using a 4 character password – if someone ever hacks it, I wouldn’t care enough to reset the password through email (which DOES use a proper password).
Then use Google, Facebook, Twitter, Yahoo to log in and have zero local password, that is, you don’t have to create a new password to log in. It works right now, try it.
Also you may not care if someone compromises your account here due to the password being 1234 but I sure as hell do because I would have to clean up afterward, plus anyone else who would have to read the spam a hacker might post here when logged in as you.
2 Likes
But there are many dictionary words, there are four of them in the
password, and the cracker would need to have them in the correct order
also. Even if there are “only” 50k words, my discrete math course was long
ago, but that still seems to be 50k^4 possibilities. That is a fairly large
number, and add in a bit of punctuation…
3 Likes
At that point, why not use zxcvbn or a similar library like mine to ensure that those basics are met, and leave it at that? It doesn’t explicitly check length, but it uses it in the entropy calculation. It can be configured to check for matching username or email, it checks for repeats (aaaaa), and it checks for common passwords. Seems to match what you want to do, while not arbitrarily limiting a user.
1 Like
Maybe having your phone is good enough? A sort of big dongle like the rotating passcode things people use. What IS good enough for determining someone’s identity? I think that part of it is “how close are you to the last time we identified you? Can you get from here to there in a reasonable length of time?” Hard to spoof that from across the planet. We have to come up with something that is not spoof-able, forgettable, lose-able, steal-able… If we use a dog, it will know if it is You or not. Now we just need lots of dogs. How do dogs do it? Build that in to the computer. Something. Someone, do something that works. If they asked it on Code Golf, someone would have an answer in a day.
In general, I agree completely with everything you said in the article. But why does anyone allow passwords to be guessed at the speed of computers rather than limiting them to the speed of humans. If you’re only allowed to try a password once per second as opposed to 1000/sec, you’ve improved the XKCD 28-bit entropy example to being cracked in 60 years as opposed to 3 weeks.
Your library checks against the 100k most common passwords? That seems impractical to do client side.
Password strength estimation is a bit of an art and science. Strength estimation is accomplished by running a password through different algorithms looking for matches in any part of the password on: word lists (with fuzzy matching), common dates, common years, spacial patterns, repeating characters, repeating sets of characters, and alphabetic sequences.
That is a lot of rules I don’t agree with. Why is having a date or a year improper? The only thing needed beyond top 100k password matching is length, and a very simple entropy check.
That’s really simple to answer, if they compromise your server and download a copy of your database, they can guess passwords at the speed of light
3 Likes
Hey, thanks for your reply.
Using my facebook account is what I did here, but I still don’t understand the concept of secure passwords for unimportant accounts. Shouldn’t you just block the hacker after a few (dozen (of thousands)) incorrect password attempts, which makes everything but the most trivial passwords ‘secure enough’?
Ages ago, messages were secure because the sender would take a stick, break it in two, then send it away with a messenger. If someone returned with a reply message and the piece of the stick (it fit against your piece) then the reply was authentic.
Allow users to create a “physical” password by breaking a small object, pressing it against the camera built in to their optical mouse, and sending the image (hashed, encrypted, whatever) to the server. Then only that physical object could reliably produce the “password” image. There, I have solved it for you.
1 Like
For unimportant accounts the right thing to do is have no password at all, which is exactly what you did! 
That is why I always advocate for logging in with your “internet driver’s license” first – it is one less password out there for anyone to compromise.
4 Likes
I like the approach : a single master password, just an algorithm, no encrypted vault to rely on: clever.
This might have drawbacks though, but it is still is better since it favors the “one password per website” principle. I would list these drawbacks:
-
Generation algorithm exposition + no salt involved makes a brute force cracker very possible
-
If an attacker finds your master password above, then it could replicate the attacks on your other known websites, provided you share the same username/handle.
You could address the lack of salt using the optional password profile (counter, rules…), but you’re no more state less then… 
Am I correct ?
And for your email password?
1 Like
Just create a new email account for every account… Wait…
I am looking at a Levenshtein distance of 1 but . However, an efficient
computation of Levenshtein distance requires you to know both values and in
this case the old value isn’t available. You simply have to generate all
the possibilities and try them and that’s approximately (Characters *
(Length + 1) + (Characters - 1) * Length - Length.)^Distance rather than
Length^2. Assuming you aren’t looking at something like BCrypt with a high
work factor a distance of one is practical but two probably is not.
A quick perusal of my keyboard shows 94 characters I can type easily.
Consider password1 to password2. Length is 9.
That generates 940 possible patterns by adding a character, 837 by
replacing a character and 9 by deleting a character for a total of 1786
passwords to hash.
1 Like
Yes, it has a few dictionaries to check against (including the top 100k passwords). It is pretty quick to check, though my library is Java, so not really intended for client side (when talking about a web application). It detects all of those additional things (dates, alphabetical sequences, spacial sequences, etc), so it can accurately apply an estimated entropy value to it… But it does not exclude anyone from using any of those within their password.
It calculates an estimated entropy (and has utility functions to convert to time to crack) and gives users feedback on how to make their passwords more secure. It has an optional method you can use to enforce a minimum entropy… But again that’s optional.
I think it’s the best compromise between security and usability, but I may be biased ;).