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.
The issue that we have to deal with isn't password-guessing so much. It's stupid users responding to emails asking for their passwords. All it takes is for the spammers to ask nicely, and two or three professors immediately give out their password.
Does it take into account how many users are going to write down their passwords on a post it note and stick it to their monitor (or something equally risky) if the password policy is any more cumbersome than "8 character minimum with complexity enabled with a 90-day forced change"?
As an example, Grimes assumes... 90 days between password change
How long you go between password changes is an irrelevant parameter, since a password change does not change the probability of success of a brute-force attack (i.e., any change is just as likely to change the password into the window of attack as it is to move it out of the window.)
Requiring frequent password change doesn't change the success statistics at all if the attacker is attacking multiple accounts. Even if the attacker is focussed on a single account, however, requiring a password change at intervals doesn't change the mean time it takes to break an account; it merely means that success is guaranteed, rather than probable, after twice the mean time (since that the mean time to break in is after exactly half the passwords have been tried.)
http://www.geoffreylandis.com
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.
Why work hard to get passwords from the people who are most worried about their security (possibly because they have the most valuable data),
when you can simply open a site, offer them to "check them for security", and let them input them themselves!
Why didn't I think of that! Man, what a genius!
Any sufficiently advanced intelligence is indistinguishable from stupidity.
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
So, there are 94 symbols, 8 characters, and 90 days to guess them in. There are 94^8 possible passwords. That's 6.10*10^15 possible passwords. Per day, you'd have to rattle through 6.77*10^13 passwords. 2.82*10^12 passwords an hour. That's 4.70*10^10 passwords a minute. Last time I checked, 47 billion is greater than 65. Granted: passwords are usually stored as cryptographic hashes so there is the possibility, but the total number of password combinations is equivalent to a 53 bit number (log to the base to of 94^8). Most hashes are longer than this, so that's not a go. While it is also true that many users will pick passwords that are easier to guess, administrators should know better, and users should be taught better (practical demonstrations?).
Excuse for why is your room always messy?
So unless the crackers get access to one of the other six people from that group (and assuming they actually remember any of that from almost two decades ago), they can try my real birth place all day long.
Have you been touched by his noodly appendage?
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.
The username is not the credential. In the design of a secure system, it should be assumed the attacker has (or can find out) all the valid usernames. The administrative usernames that are defined by the implementation (i.e. the 'Administrator' user, the 'root' user are well-known anyways, and in many cases, required to be active by various software products used in a system.)
The security is in the key (or password), i.e. the secret credential.
Sending 3 attempts is cheap. Generally there's no need to know if the lockout attempt was a "hit" or not.
Also, many systems that implement password lockout will notify the attacker of the password lockout, once the account's been locked rather than state "Invalid Password".
It's foolhardy to place any trust of security in or reliance in difficulty of discovering a username.
No, it isn't that simple.
Considering just about every system today has the user's e-mail address or some combination of first initial/name last name as a username, this is a waste of time and misdirection. It is much too easy to come up with someone's username, even if it isn't one of the above patterns. The username is NOT designed to be part of the security scheme because it is simply ineffective, gives a sense of false complexity (security thru obscurity) and is a major PITA!
(Hmmmm...which username did I use on this site? Is this one that allows e-mail addresses? Does it mandate a certain length of username? Was my preferred name already taken? Hopefully it'll tell me if I screw it up.)
Learning HOW to think is more important than learning WHAT to think.
Divide that in half again. You can break an 8 character password in to two 4 character passwords and crack them in parallel
This is simply not true. In parallel, you can do two attempts at once, but dividing it into two 4-character passwords is definitely not possible. If it were, you could divide each of those into two 2-character passwords, each of those into two 1-character passwords. You'd then have eight 1-character passwords to crack and have to do 8 * 256 = 2048 attempts to crack any 8-character password (assuming each character could be any ASCII character, fewer if it's a restricted subset). This is only the case in very-flawed systems where each character can be tested individually. There was an OpenSSL vulnerability a while ago that made this true - the return time could be used to infer which byte of the key was the first incorrect one - but it isn't the case on any common system.
Divide that in half again. You can break an 8 character password in to two 4 character passwords and crack them in parallel
Ex falso quodlibet.
I am TheRaven on Soylent News