I have a question, I read that you should never use a password that is a word in the dictionary because people can use hacking programs to go through everyword in the dictionary and find your password.
Makes sense, but why don’t websites do what this one does, if you try, say five times, and fail, you’re just locked out. That would esentially kill most dictionary type attacks because it would take a long long time, if you could only try five times a day.
I worked at a place once where we had a similar thing, if you tried three times and failed it locked you out and you had to go to the computer guy to have him reset it. And it was sad on days when he wasn’t there because you couldn’t get in to your email at all.
I just wondering why everyone doesn’t limit the number of times you can try each day. It would seem to stop most dictionary type attacks.
But what if the hacker could download the master password file, where all the passwords are stored?
If the file is in plain text, obviously there’s no need for further hacking: he’s got the keys to your kingdom. So in order to minimize the loss if that happens, password files are typically stored as hashes of the passwords. That is to say, the actual password is not stored; instead, a scrambling/encryption process that only works one way is applied to the password, and the result stored in the file. So there’s no easy way to “reverse” the hash and come up with the original password.
But – the hacker could apply the same hashing algorithim to “aardvark” and see if the resulting hash matches anything in the password file. And if it doesn’t, then try “Aaron,” “Adam,” and so forth. If he gets a match, then he has your password.
But if your password is “13Gr8Time$4Allz” he is still stymied.
That system is defeated if somebody can get a hold of your encrypted password file/database. Then they can just run a dictionary attack against it for as long as they want on their own computer. It is generally a good idea to keep your password file as secure as possible, but shit happens.
And correct me if I’m wrong but an attacker doesn’t even have to get at a master file, they can sniff your network and capture the hashed password as it is sent from a workstation where somebody is logging on. Doesn’t get them every password but often one is enough.
To add to the fun, there are databases available of prehashed passwords (millions upon millions of them), so once an attacker has the hash they don’t necessarily have to do a brute force attack, they can simply look it up. These tables will depend on the exact hashing algorithm and IIRC are limited to dictionary words and simple combinations of them, but it can make cracking a password trivial.
Sniffing the network can be useful with simpler challenge-authentication protocols. A secure response to that is using something like NTLMv2, which uses a set of encrypted challenge/response exhanges between client and authenticating server that are unique to each interaction.
One other note is that this is a very poor solution.
Dictionary words are bad not because they can all be scanned, but because that limits the number of combinations. With six characters, combining letters and numbers, plus uppercase and lowercase you have 6[sup]46[/sup] possible passwords (which appears to be a 36 digit, very large number.)
For a password like this, you can give a user thousands of free tries without worry that the password will be cracked.
With a dictionary word (which will fairly invariably be in all lowercase, probably between 4 to 8 characters, and a relatively common word), you’ve got maybe…50,000 or so words that might be used. Now if I fail you if you mess up three times, that means that I’ve got a 3 in 50,000 shot of guessing your password, but I don’t want to try 3 times since that sets off alarms, so instead I try one each day. So this means that I’ve got a 365 in 50,000 chance of guessing your password in a year, or rather a 1 in 136 chance.
At a 1 in 136 chance, if I’m attacking something like the Straight Dope, where I can pick up all the usernames as a guest, this means that I can attack several thousand people a day. Over the course of a year I’ll have figured out the password of hundreds of Dopers, and no one will be the wiser.
Any password worth protecting should be secure enough that you can give a regular user hundreds of tries in a day and still not have any worry of passwords getting cracked.
Because you have to set up a mechanism to deal with the angry users who mistype their password, or forget it, and then contact you angrily about it.
Remember: the better the security, the less the convenience, and vice versa. The question is determining a threshold that balances.
Also, the more secure you require the passwords to be, the more likely people will write them on a post-it and put it on their monitor. Your pet’s name is a lousy password from a security point of view, but it’s easy to remember. Similarly, b&8jfs09-e might be great for security, but hard to remember – and if you require passwords to be changes regularly, you’re just asking for it to be written down somewhere.
In addition, it’s fairly easy to mistype a password and not realize it, since you can’t see what you’re typing. I’ve had people try to log in five times and get it wrong all five until I typed what they were supposedly typing myself.
I work with one (not particularly obscure) commercial software platform where entering the hash works as well as entering the original password. :smack:
In the old days, if you had an account on a Unix system, you had access to the encrypted password file. It was a simple matter to copy that file to your own computer and run a dictionary attack to find other people’s passwords. I can’t remember if the root password was in there, but I seem to recall it was.
There are also situations where you don’t even trust the administrator of the system. root will always have access to the password file and can dictionary attack it all day long. If he learns your password he’s free to go over to your bank’s website and, just for kicks, see if you used the same one there.
The system bypasses hashing the input if it’s already hashed? That sounds like someone went to a great deal of effort to create a gaping hole in their system.
And, of course, to counter this, there is the increasingly common practice of “salting” a password.
The way that works is that, instead of storing the hash of your password, the value stored is the hash of your password plus something that is (hopefully) unique to the system in question.
So, if the salt is, say “blickersnish23899”, simply concatenated onto passwords, and your password is something stupid like “secret123”, the actual value that’s hashed is “blickersnish23899secret123” The great thing about this is that, even if the salt and the method of combining the salt with the password are known to an attacker, if the attacker gets the list of password hashes he can’t compare it against a precomputed table of dictionary words and combinations. He has to recompute all those phrases combined with “blickersnish23899”, which, for an exhaustive dictionary, could take months.
I disagree that any of this is much protection against an adversarial sysadmin. Anyone worth his wage as a sysadmin would just create a login script that saved off the password before passing it on to the actual hashing algorithm, or instal a keylogger, or any of dozens of other things to get your password in plaintext.
Assuming that you are using a modulo-based hash, then this is called the discrete logarithm problem.
Classically, this is quite difficult to compute, you are correct. However, one of Shor’s great quantum algorithms is the calculation of the discrete logarithm in a polynomial amount of time (which is part of the buildup to factoring).
So, if a quantum computer is ever built, not only will RSA-style security be compromised, but so will passwords.
Back in the good old days on Unix (at least, versions of Unix that I used) when /etc/passwd was readable to the world (it had other Good Stuff in it besides passwords, like home directories) the salt was part of the encrypted password field in /etc/passwd. If I recall correctly, the salt was the first character in the password field. You took that together with the cleartext password entered by the user, ran the two through the publicly available encryption routine, and saw if the resulting encrypted password matched the balance of the password field. The salt was generated randomly whenever you set a new password.
It seems to me that it would be pretty easy to circumvent a dictionary-style attack while still choosing a “simple” password. Just choose a word from a different language (e.g. take a one-semester course in icelandic or hungarian or gujarati) and take a word from that language. Hackers are not going to have the words of every possible language in their password toolkit.
I am assuming and so will password-security, not passwords themselves. You invert the hash and you get a huge set of passwords that hash to the same thing. They can be used to breach the security that uses that same hashing algorithm, but how would you know which one of them was the original password?