h a l f b a k e r y"This may be bollocks, but it's lovely bollocks."
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
If a password is 6 characters in length, it is reasonable to expect all six characters to be correct. However, if it is 60 characters in length, and 10 characters are wrong, you still have 44 more correct characters than the 6 character password and so is it not reasonable to accept it?
Example:
Pass=mydog123
<< midog123 should be rejected
Pass=donty0uth1nk1tsal0v erlyd4y0uts1det0day << dony0uthink1tsal0v errlyd4y0uts1det0day should be accepted
As some people may wish to have extraordinary levels of security, the fuzzy match option should have an opt-out. Also, initially I was concerned that it would be a problem for public machines, where someone reading your keystrokes could get away with a few mistakes, however on further consideration the fact that this will encourage you to have a sixty character password that is going to be hard for someone to watch you type instead of a six character one for which they only need to remember six keypresses will outweigh this danger.
It may be wise to warn the user that they made a mistake whilst still letting them in, to avoid them getting into the habit of making that mistake and slowly drifting further from the original password string, losing the flexibility of the system as they reach the edge of the fuzzy boundary.
Alternatively, the password string could be deliberately allowed to evolve, so small changes which are repeated regularly start to feature in the stored password string, and over a long period of time and numerous (conscious or unconscious) minor changes to the way a password is entered means that the original password will no longer work. This bypasses, to some extent, the need to keep bugging users to change their passwords.
There are some parallels here to the use of a physical signature for the verification of identity.
Error Correction
http://en.wikipedia...tion_and_correction
From an information theory and communnications perspective... [Jinbish, Oct 21 2009]
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Destination URL.
E.g., https://www.coffee.com/
Description (displayed with the short name and URL.)
|
| |
Love the "evolving password" bit. |
|
| |
I once was given a server password that was "youll_never_guess_this_ password_in_a_million_years". He was right - I wouldn't. |
|
| |
I've considered this before. I call it "fuzzy passwords". |
|
| |
A bit of a disadvantage with this is that you'd have to store and transmit the passwords 'in the clear'. It's generally better to store and transmit salted hashes, because then even if a hacker can access the data (in a password file or in transit over the network) they don't know the user's password. |
|
| |
The other issue is how you decide how close the two entries are. Naively comparing char by char probably reduces security by quite a bit, because of how good passwords are generated by users: 'letters, numbers and symbols' is likely to become 'letters plus one digit plus one symbol'. This is still okay when all must match exactly, but becomes more susceptible to all-letter guesses when not. |
|
| |
[Loris], good criticisms there. Particularly on the subject of storage and match, there are a number of fuzzy hashing systems designed (e.g.) to encode the words by their sounds or similar. An imperfect example is the Soundex algorithm. Whilst this is not my recommendation for an algorithm, it is an example of a many-to-one fuzzy hash in which a minor change to the input data does not have to require a major change in the hash. |
|
| |
Then again, networks rarely transmit passwords as salted hashes in practice, they usually rely upon infrastructure level security (e.g. SSL) during transmission and then calculate the hash on receipt. If a network sends a salted hash, then it means a bogus node only needs to retransmit the same salted hash to gain access ... the plaintext password is not required. That is a serious problem as if Jim manages to get a dump of your users table, with salted hashed passwords, then usually it is unusable data... however if you are transmitting salted hashes over the network, he just needs to override the hashing process locally (where he has full control) to be able to log in as any account in the table. |
|
| |
This leaves the only real problem of plaintext password storage that someone could hack into the server and steal the passwords. The practical answer here is that yes, it is an advantage to have them hashed, but only a minor one as anyone able to hack into your database can almost certainly get whatever data he wants from there directly without having to 'compromise accounts'. |
|
| |
Your other concern, that of passwords being mostly letters with a few odd numbers, that could be easily dropped in the fuzzy pattern, can be reduced if not eliminated by password strength requirements. Such requirements are already common, e.g. min X characters, must contain at least Y letters and no fewer than Z numbers. Also note that the fuzzyness of this match (as I had intended anyway) is related to the length of the password; a short password "mydog123" would have no fuzzy-match, whereas a much longer one would already have substantial anti brute-force strength even in the absence of numbers and letters. |
|
| |
This is great. I like the signature allegory, and the evolution - isn't there some kind of 'data entry signature' (like the old fashioned morse thing where a receiver could identify senders purely on the 'style' of their sending)? |
|
| |
I agree that properly secured passwords may seldom be used in practice. I won't go into the details of salting because it takes a lot of space to do it justice and get it right. One could encrypt the salted hashes in transit (as you've mentioned) - you can do that to unhashed passwords too of course, but by hashing them first you've reduced the attack surface.There are other advantages to hashing too; people do tend to reuse passwords for instance. |
|
| |
Regarding the second issue, I think you'd make the system more unwieldy by requiring Z numbers (and symbols?). People would probably just rely on the fuzzy matching to get by without as far as possible.
But it's not a show-stopper. Use a match-table where characters are near or far from each other to assign the values. You almost certainly want to allow for insertions and deletions as well as substitutions; there are algorithms developed for genetic analysis which do this sort of thing already. You'd then look for a certain matching score rather than a level of identity. |
|
| |
As time has gone on, I've seen the recommendations for passwords become progressively more strict. First it was 'don't use any of this list {'password', partner/child/pet's name...}.' Then 'don't use a dictionary word', 'include mixed case', 'don't use two dictionary words', 'include symbols and numbers'.
Eventually it'll probably be 'batter the keyboard at intervals and move the mouse, then memorise the generated string: r&6Bq29;@1". I'm not looking forward to that. |
|
| |