New Password Idea

Here's a new concept that will help reduce locked accounts for Corporate users permanently:

It's called, "close enough technology". When typing in your password to log into a machine, how many of you fat-finger it, and how often? Do this a few times in a workplace, and you may require someone to reset it. Add in several thousand employees, and you now have a full-time position resetting passwords.

But honestly, how many of you want to be the password Nazi, if the users DO know their passwords--they just can't type in the mornings without coffee?

Close Enough technology allows the platform (Linux, Windows, OS X) etc. to "understand" your password even though you mis-type it, and be able to match it within a few characters (globally or group-level configurable) and still let you in.

Here's how it would work:
1) Type in your username, which obviously will have to match, because you can actually SEE it onscreen.
2) Type in your password, but in this example, if your password were "letmein", but you typed, "letnmein" (accidentally adding the extra "n"), the technology would know that you really knew your password, you just didn't type it in correctly. The machine lets you in.

NOW! Also configurable would be the number of times you can fat-finger the password (say, 1-3 times), how many extra or fewer characters, and how many completely wrong characters, before the platform requires an exact match of the password. THEN, the exact match must be met within x number of tries before the account is officially locked out.

I feel this still to be quite secure only because the username must be matched, so similar multi-user passwords could never be used unless the username were shared.

Comments welcome. I reserve the right to suggest this idea to other entities.

that's a nice idea that can

that's a nice idea that can work, especially if there's some restriction to the number of fatfingers. Otherwise, a user could add a number of 100 wrong letters per password and that will be a serious sec hole. But that's quite obvious
The other problem is based on the encryption of passwords. I think MD5 is used, and if that's the case then "close enough" is equal to "not close at all". For example
letmein - 0d107d09f5bbe40cade3de5c71e9e9b7
letnmein - e63c249ce30d5483118701d835cfa8cb
if the computer generates a hash for every possible wrong password then it's gonna be slower. if the encryption changes it's going to be less safe, as MD5 is very, very secure due to this feature. It's a good idea, but idk if it can work...

Nice at first sight, but...

This idea looks nice at first, but implementing using current methods is not safe. On this site something similar is discussed.

As et3rn1ty notices, MD5 is an algorithm that is frequently used to store passwords. Please note: it is not an encryption, but a hash. The difference between those two is very important! An encryption algorithm is a two-way operation, a hash is just one-way per construction. Let's just take two simple (invented and certainly not safe algorithms):

for encryption: put the first N letters at the end (a bit like pig latin)
for hashing: count the number of e's in the word and add 10 times the number of i's in the word

So let's assume the password is 'letmein' and N = 1
encrypted: 'etmeinl'
hashed: 12

As discussed: both algorithms I use are very weak, but allow you to see the difference more clearly.
If you know N (the key) and you get the encrypted value, you can apply a reverse encryption (in this case: put the last N letters at the beginning) and you get the password. With a hash, you can't compute the original password. The hash '12' can both mean 'letmein' as 'let her in' as 'make me a sandwich', ... To introduce a little terminology: when two passwords have the same hash, it is called a collision.

When you encrypt a password, the actual password is thus retrievable (because your application also needs to know the key). So a hacker can also find any password. A hash will not reveal the actual password. But that does not mean a hash is 100% safe

Coming back to this idea to allow a little inaccuracy on a password for it to match. Technically this is possible, but not with the hashes we use nowadays (MD5, SHA, ...). Because a hash is so different from the original password, it is impossible or very computing intensive to determine whether a mistyped password matches a certain hash.

Just consider this: we allow 1 character to be mistyped, for a long password this means a lot of different combinations ('letmein','Xetmein','lXtmein',... where the X means that character can be a to z (and numbers and other characters)). So in our example, you would need to calculate a lot of hashes (for every X you get at least another 36 hashes (26 letters + 10 digits, (perhaps even 26 extra for uppercase) so even more (let's say 200 in total) for extra punctuation and such). We have to calculate approximately 180 passwords (only letters) and 1400 when including other characters. If we allow more characters to be wrong, it gets much worse on calculations: if we allow only letters and 2 wrongs are accepted, you get over 28000 passwords to calculate for this simple case (more that 50000 if we also accept digits and don't even bother with punctuation: over 1.5 million).

What a hacker would need to do, thus, is to enter a random long string, with a bit of luck one of the passwords will create a valid hash and the hacker is in without knowing the password. Also, a long password will take very long to validate, thus the machine practically brute-forcing itself.

As such it is not practical to use classical hashes like MD5 to store and validate the password. An open option is storing the password in plain text or encrypted (which are more or less as safe, because for an encrypted password to work, you need a known key).

Perhaps it is possible to construct a hash algorithm that accepts a bit of inaccuracy on the input (if such doesn't already exist). I'm sure that such a system could work, but you'd need a lot of work done cryptographically to store passwords securely while allowing the fuzziness of your password entry.

On a side note: MD5 isn't that safe: some methods are known to create a collision, so when a hacker gets an MD5-hash he can invest a lot of time and resources to get a password that matches this hash (possibly not your original password, but it will get him in as well). In practice some other tricks are also used to store (MD5) hashes of a password in a safer way.

But I do have an idea you might like: (not my own, though)
A less difficult way to make logins safe without the hassle to remember passwords, is using gestures, certificates, dongles, smart cards, etc. In Ubuntu there is already a way to physically log in at a computer without using a password:
the PAM architecture has a usb module which allows you to use a USB stick or Flash card to contain a file which is used to log you in. The Ubuntu repositories contain this module, so there is little effort in installing.

So imagine that: you arrive at work, enter your user name (or click the icon) and enter a USB drive and your desktop will load. If you forgot your USB drive, you can always use your regular password to log in. The only problem with this approach is this USB drive could get lost or get stolen. Luckily, one can always log in with the password and disable a certain USB drive from functioning as key.