Slashdot Mirror
Calculating Password Policy Strength Vs. Cracking
snydeq writes "InfoWorld's Roger Grimes offers a spreadsheet-based calculator in which you can key in your current password policy and see how your organization's passwords might hold up against the number of guesses an attacker can make in a given minute. The calculator includes results for four different password entropy models, and is based on length, character set, maximum age, whether complexity is enabled, and the number of guesses per minute an attacker can attempt. As an example, Grimes assumes an eight-character password, with complexity enabled, a 94-symbol character set, and 90 days between password changes. Such a policy, typical for many organizations, would require attackers to make only 65 guesses per minute to break — not at all hard to accomplish, Grimes writes."
Most systems have a "three strikes and you're out for 5 minutes". So that kind of makes 65 guesses a minute impossible. You'd have 3 every 5 minutes.
The solution is not complexity. It is limiting the number of attempts and logging the process and having a HUMAN review the logs on a daily basis.
Some systems will intentionally "lag" you on a failed password attempt, or wait some time before the next guess. So you can't even MAKE 64 guesses a minute.
Others will lock you out after 3-5 attempts.
Kind of stops this flat, hmm?
With 8 characters you have to make on the order of 10^15 guesses. To go through all of those guesses in 90 days you have to try 783.9 million combinations per second.
And 65 guesses per minute is hardly something that should trip ANY rule of an IDS.
Privacy is terrorism.
break this password 1bbe3bcb8c840c7309d460d8d5b8e709 how long did it take? (used the echo -n "string" | md5sum to get that hash, with ofc another word then string)
http://freelinuxguides.wikidot.com
It doesn't matter where the 3 attempts come from. On the 3rd failure, the account is locked.
Yes, this does allow for DoS attacks. So what? It's better to have the legitimate owner locked out so that he can call to find out why than it is to have his account cracked.
Did he remember to model the fact that if you make your password requirements sufficiently rigorous....
(A) People will increase risk by having to write them down, or
(B) People will try to stop using your system, which is a different but related kind of failure?
First off, there should NOT be any indication whether the username was valid or not. It's as simple as that.
Secondly, the issue really comes down to whether a DoS attack is better/worse than a compromised account.
I'm on the side that believes compromised accounts are WAY worse than a DoS attack.
Requiring password changes on a regular basis doesn't improve security, it actually lowers it IMHO.
Whenever I've seen institutions start to require this policy, I explain expect a larger number of people to tape their current password under their keyboards.
The other option I see people do, is use a password combination like this "MyCurrentPassword!05" where the "05" is the month. So, in a few days from now, the new password will be "MyCurrentPassword!06" and so on. Even if you require 12 unique passwords in 12 month period, they will be cool, and not really change the password.
The #1 problem with passwords in my opinion, is that most systems have a "remember password" checkbox. That checkbox should be BANNED!
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
Distribute private keys. Enforce a policy where the private keys can be revoked. Use a physical token.
Make it so the party logging in needs something they know (a private key) and something they don't know (the random number from the key fob).
It's easier to convince the People In Charge that this is necessary *after* a break-in.
It's better to simply *be* the Person In Charge and establish the policy, and enforce it.
Either you're serious about security or you're not.
One problem is that laypersons don't understand just how simple it is to break password authentication, and don't understand that if their password is a dictionary word or even a misspelling or l33t of a dictionary word, they've probably already been compromised. Going further, they don't consider that maybe the person doing the attack is a competitor or disgruntled former employee who *knows* the names and birthdates of all the spouses and children of the whole sales department.
Then there are people who won't take IT security seriously until they've lost a defense contract or a faced lawsuit over a leak of proprietary information.
-fb Everything not expressly forbidden is now mandatory.
It's not an irrelevant factor. Without any password changes, you are guaranteed to get the password eventually. If you do change passwords, you are trying to hit a moving target. You might get it, you might not, and even if you do, you don't have long before you have to run the attack again.
You misunderstand the risk. Password complexity policies offer protection in case the password database itself is compromised, when account lockout policies are of no use. The idea is to give everyone enough time to change their password before the attacker is able to decode the database (or authentication caches or packet captures or whatever).
I'm proud of my Northern Tibetian Heritage
It isn't irrelevant if you change your password during the attack to something the attacker has already tried.
Nope. Think about it as a statistical thing. There's an equal probability that you'll change your password to something that the cracker is just about to try, as there is to change it to something the cracker hasn't tried yet
Lets say you change the password after the attacker has made it through half of the keyspace...there is a 50% chance that this new password will never be guessed
It's easier to think about statistics if you think about large numbers. Suppose the cracker is trying to crack 1 thousand user accounts, and the password change comes when he is one ten thousandth of the way through. Yes, on the average there's some chance that a users will change their password into one that he's already checked (and if they never changed their password again, they'd be immune from getting cracked.) However, to balance that, an equal chance exists that they happen to change their password to one that he's about to try. There's no net change in the statistics of cracking.
The same statistics work, on the average, whether the cracker is trying to break into one account.
http://www.geoffreylandis.com
You're right on target.
The real question one wants to ask: what maximizes the security of security measures?
For passwords, we want something that's easy to remember and hard to guess. Hard to guess means it has to appear random: it has to be chosen with a large amount of entropy from the set of valid passwords. In other words, it needs to have a high amount of information content.
"Easy to remember" is at odds with "high information content": the more you have to remember (generally speaking) the harder it is. However, there are mitigating factors.
One is the rehearsal effect: by training something (repeatedly retrieving your password from memory), you become better at it. This can somewhat mitigate the problem of long, hard-to-remember passwords.
Another trick is to exploit the way human memory works. It doesn't just store a big array of bytes like a disk does. I conjecture that the more connected a piece of information is to other pieces of information, the easier it is to remember. (the ocw.mit.edu psych 101 tells that this is certainly true for short-term/working memory.)
A neat trick (recommended by root@myuni) is to come up with a list of words which mean something (say, they're part of a nonsense phrase you made up*), picking the first letters**, adding some punctuation, and using that.
** Maybe I'd recommend picking the i'th mod n of word i where len(word i) == n, due to language statistics issues.
* Say you can remember "Ash nazg durbatuluk, Ash nazg gimbatul, Ash nazg thrakatuluk, Agh burzum-ishi krimpatul" (one ring to {rule,find,bring,bind} them all). Pick as your password AnrAntAglAbi.
If you don't remember geek poetry, pick a list of people you've had crushes on, ordered chronologically, and capitalize every one you've actually been with.
Note that your password must contain at least one upper-case letter. If it doesn't, you have bigger things to worry about than the security of your slashdot account :p
The sticky issue, from a theoretical standpoint, is that you want a password that's very random, but randomness (i.e. entropy) is an attribute of the distribution, not the sample. That means you can't really say that choosing "password" isn't random.
The practical upshot is that you want to choose passwords that evil people are unlikely to guess, which is dependent on what typical people use as passwords. So, by enforcing "nasty" rules, you force users to select something with at least a little entropy (_which_ upper/digit/punct and where it is). Sadly, it'll be Passwo!1, Passwo!2, Passwo!3, etc.
An interesting rule: no three consecutive members of the same character class.
It's not an irrelevant factor. Without any password changes, you are guaranteed to get the password eventually.
With password changes, you get the password even quicker, because there are only a very small number of sequences that people can think-up once per month, compared with a larger number of unique passwords that they can think-up just once.
Mod parent up as one of the few who understands how forced password changes are generally bad for security.
When asked, most system admins do not know what the single security issue that is addressed by forced password changes: limiting the amount of time a compromised password can do damage.
The problem is that any forced change time that is short enough to do any good with this (like 30 days) would cause users to always pick the most memorable (i.e., least secure) password that meets the requirements. Worse, it's more likely to cause every monitor in your office to have a password-laden sticky-note. If you have a 90-day change time (about the standard), that gives an average of 45 days that a compromised password can do damage, which is way too much.
Last, forced password changes are still almost certainly nothing but security theater, because once an account is compromised, it's easy to re-compromise it with a keylogger or similar background software.