Bruce Schneier | |||||||||||
Schneier on SecurityA blog covering security and security technology. « Obama's Cybersecurity Czar | Main | Yet Another Schneier Interview » December 11, 2009Wondermark on PasswordsPosted on December 11, 2009 at 12:33 PM • 14 Comments To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter. Johns • December 11, 2009 2:03 PM Funny. But he used my password in it! Now I can't share it with my friends. :( Andrew • December 11, 2009 5:50 PM The person in the comic is quite obviously guessing (even before his admission in the last panel). Much of the humor in this comic is due to the incongruity of the human guard not responding to that as a real human would. Peter E Retep • December 11, 2009 5:51 PM Bruce, Roger • December 11, 2009 9:21 PM @Andrew: " ... could we come up with a way to distinguish between ..." Problem is, normal rate limiting just needs to count the attempts. Any more sophisticated method needs to store either the actual guesses, or less opaque information about the password (so goodness of fit can be recorded.) For a computer (as against a human brain), this can create new security problems (it's the reason why on failed login attempts, we send the userid to syslog but *NOT* the wrong password!) Clive Robinson • December 12, 2009 12:56 AM @ Andrew, " ...and take appropriate action without revealing information about the password to the potential attacker?" You might be making an assumption that is not (or should not be) true, which is the system knows the plaintext password, or how the specific user constructs their passwords. For a correctly working password system the only information the system should know is, `if the current password guess matches or not` nothing else. It's the fundemental idea behind the original *nix password system, which many modern password systems appear to have forgoten in order to get "more security" (to prevent users re-using passwords etc). Ignoring for a moment this and Rogers (@9:21PM) other major point about storage of the "attempts". What you are looking for is a (Delphinic) oracal combined with a Turing test. Both are problems that Hard AI has not solved and arguably cannot solve without the use of quantum computing (see info on Roger Penrose and his search for Quantum structures in the Human Mind). This only leaves a statistical analysis of the "supposed user" input. Thus the question falls back to what you are trying to do, 1, Help the user remember. In the first case you can model human behaviour on past experiance in the "general" or "specific" case. The "specific" case would reveal meta knowledge of the user and thus their password which would aid an attacker. The "general" is unlikley to be of help as it would only do what the attacker should be doing anyway which is to guess the password. How do you work towards an "unknown" from a zero knowledge postion. Which is a more restricted case of the problem cryptographers face when faced with a new cryptogram. To which the answer should be `only by brut force search or random guess'. Thus anything else does reveal something about the password or the user of the password. Both of which in theory (and practice) will help an attacker get the actual password. Peter E Retep • December 12, 2009 9:53 AM Dear Bruce, When it is in your own economic advantage to use a computer, What do you think? BF Skinner • December 14, 2009 7:07 AM @Roger "send the userid to syslog but *NOT* the wrong password!)" We used to, and likely some still do. That's why it was identified as a bad practice and put on the list of things to test for. The thinking then was "well only the SA can get to it and they already have root." This is the thinking of a developer (occasionally O&M) not someone in security. The problem • December 14, 2009 9:06 AM @ Andrew - Obviously you give information by saying 'wrong' as well, but the simple elimination of an invalid password is the least information we can get away with giving. If you allow more guesses if the guesses being given are 'close' rather than 'far' from right, then by sensing the number of guesses allowed we can infer how 'close' to right we are guessing. The best option I have seen is a simple method that penalizes guesses exponentially. That is, first wrong guess results in a 1s lockdown, second in 2s, and so on. After 15 wrong guesses the lockdown is 4.5 hours. Of course then DoS issues come into play. Travis • December 14, 2009 10:10 AM @ The problem "If you allow more guesses if the guesses being given are 'close' rather than 'far' from right, then by sensing the number of guesses allowed we can infer how 'close' to right we are guessing." You could pretend you are not allowing more guesses by giving the response that they have guessed too many times and must wait awhile. But you could be actually checking each guess, and if it is correct, look back and see if they had guessed something similar before hitting the limit on number of guesses. If so, allow them access. If not, continue saying they are at the guess limit. Adam • December 15, 2009 8:43 AM @Travis: The problem with that is that you have security in obscurity concerns - if the attackers know the methods your system is using (which you should assume they will eventually find out) they will be able to tell when the system is 'just pretending' that you've guessed too many times and infer the additional information as mentioned above. Arkh • December 16, 2009 5:29 AM @The problem You could imagine a system where some false password put you in use of a locked down with random info version of your system. It opens new vulnerabilities, but the attacker would have to work a little to know what he got access is on a random VM.
Post a comment
Powered by Movable Type. Photo at top by Geoffrey Stone.
Schneier.com is a personal website. Opinions expressed are not necessarily those of BT. |
|
Comments