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.
G0a$e.cX
So the attacker hashes the passwords he's trying. It would really only be useful if the attacker was unaware your password was a hash. Which means it's no use for company policy.
Still. Not a bad idea for my personal accounts. ;)
Deleted
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
OK... But for how many minutes?
If it should be the maximum possible amount (90 days) - then it is only 8424000 possible passwords (65 password x 60 minutes x 24 hours x 90 days).
Now, I may be wrong but somehow I have a feeling that there are far more combinations for 94 characters.
Also, this page makes some quite different claims regarding the time it takes to break passwords depending on their complexity.
Like 22,875 years to go through all passwords for 96 character password - if you are doing 10000 passwords per second.
Mit der Dummheit kämpfen Götter selbst vergebens
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?
All the systems I have access to or control myself allow only certificate+password logins (with
per-accessing-machine and per-user specific certificates for easy access management and revocation)
but will happily ask for a password on any certificate-less login attempt.
Also, remote root logins are completely disallowed.
Combine this with fail2ban and brute-force attacks of any kind are pretty much a non-issue.
Who cares about password strength anyway? A four letter password is still stronger protection than most people give. The weak link in the chain is and always has been humans. I've found that the security questions to reset the password are easier than the password to crack. Either that or just wait for some Security Official to slip up and sell a hard drive with passwords and usernames on ebay.
If our elected representatives no longer represent us, do we still live in a Democracy?
I'm glad my password is 100 characters long with some from English, some from Greek, and some from Klingon.
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.
Must be, the number of attempts per second makes no sense. I get a COMPLETELY different answer based on similar "data" from his article:
Even if the password is "trivially" generated:
symbol word symbol word symbol: eg. _orange*bear#
would require 10,000 attempts per second to crack under these circumstances (roughly). Assuming that the defender uses ONLY this exact pattern:
The symbol characters add 4 bits each, or 1000 multiplier for 3 (very rough). Choose two words from the dictionary, say limited to 10,000 choices each (the author states that it could be chosen from a set of 50,000). 100,000,000,000 possibilities to run through, If 100 days given, 1,000,000,000 have to examined per day, 86,400 seconds per day, or just over 10,000/second. Contrast to 65/minute.
And that assumes a VERY limited password.
I should download and review this, but I really don't care enough.
But I will try to guess where that number could come from:
Two words together, nothing else. 100,000,000 combinations, 1,000,000 per day, or just over 10 per second.
A single dictionary word, followed by a number. 100,000 combinations. Finally, our attack rate can be 1 per second.
Just another "Cubible(sic) Joe" 2 17 3061
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.
90 * 24 * 60 * 65 = 8,424,000
8 ^ 8 = 16,777,216
So if you used an 8 character set, 8 characters wide, you'd get broken by Roger's attack. And you'd be an idiot.
Dictionary attacks? Ask yourself this: What other attack vectors do you open up by using this fame-monger's advice on how to mitigate dictionary attacks? Does Roger address that concern? Might that be because he doesn't know what he's talking about, and is more concerned with getting column inches and his face on your computer screen than he is with security?
Just a thought.
Stop-Prism.org: Opt Out of Surveillance
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.
While Roger Grimes's intentions are good, in making that spreadsheet he's just wasted a lot of effort that he could have spent drinking beer and kissing women.
Firstly, any analysis of real-world passwords in use in, er, the real world, will scream that they are far too weak. That is not news. At all.
Secondly (and this is the hard part for geeks to understand, so: l i s t e n - the strength of a password decreases the greater its theoretical strength becomes. Yes, that's DECREASES.
Why? Because if my password has more than a couple of numbers and some upper/lower case letters in, I will write it on a sticky note and attach it to my monitor - sometimes with the words "password to payroll system" or whatever also written on it.
That is reality. Now, can we all stop this nerdy crap about password strength and do the real work of thinking about the human factors involved in security? That, I am afraid, is where the hard work is. Any idiot can make a spreadsheet.
"And the meaning of words; when they cease to function; when will it start worrying you?"
Somebody programmed somehow useful web page (if you dislike excel, that is): http://olli.jarva.fi/passwordstrength/?en
You enter your password into a web form. Because the checks take a lot of CPU time I will do it off line and email the results back to you (so give me your email address). In addition I will do checks that are specific to your bank, so please tell me that so that I can better assess and help you ....
OK: I jest - but I suspect that a few people would be suckered by that!
The spreadsheet purports to calculate the number of guesses per minute needed to break the password. But in how much time? Also, the comment next to the final result says that it represents guesses per second. 65 guesses per second should cause some notice somewhere in your system. TFA claims that "usually I'm able to break most passwords in under three days, if not in hours". I'm guessing that "most" refers to six-character, birthday or pet-name passwords. My takeaway is that the most effective defense against poor passwords is a [3]-minute lockout after [5] wrong guesses. This will limit the bandwidth of the attack to an unusably low rate. I just can't resist adding that it is really easy for us to enforce password policy for all services domain-wide by a simple policy setting on our DC. In our cluster computing group, where Linux boxen are the norm, chaos reigns and it is a really good thing that those machines are not accessible from the external network.
This is not a self-referential sig.
Set up 2 random number generators, 1 from 1 to 20 and the other from 1 to 6. Roll the first one, and use the consonant that is at that position in the alphabet (not counting vowels, so 1 becomes b, 2 becomes c, 3 becomes d, 4 becomes f, etc). Roll the second one and do the same thing but with vowels. Alternate vowels and consonants for about 10-12 letters. You should end up with something like this:
dobamohaqes
Completely meaningless, but pronounceable and therefore easy to remember. If you want, you can add some funny capitalization or some numbers at the end.
Really the 4 number password for your pin code is strong enough (10000 combination) Any attempt to brute guess these is going to be detected and any further attempts will be stopped.
On this subject, what algorithms are out there for establishing a user's password strength? I see some sites do this, but I am not sure what mechanism they use.
Jumpstart the tartan drive.
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
Good metaphor. Guessing a password by brute force is like a blindfolded man trying to shoot a car on the highway by the technique of shooting a bullet, moving the gun two meters, shooting another bullet, and repeating.
Now, if the cars are not moving (and he knows that there is a car on the road somewhere), this technique guarantees he hits one eventually; while if the cars are moving, there's no such guarantee... but, statistically, he hits the same number of cars, on the average, whether the cars are moving or not. It doesn't make any difference if the cars are moving or not to the average.
LIkewise, on the average, it makes no difference whether the passwords being probed for by a brute-force search are changing or not. This should be obvious if the cracker is trying to crack, say, a thousand systems, right? So, you should agree that a system administrator who's administrating a thousand accounts, ought to realize that the system is no safer against getting cracked if he makes his thousand users change their passwords every day or every year.
and even if you do, you don't have long before you have to run the attack again.
Now, that is a different story. If the cracker doesn't install his malware on the cracked system once he gets the password, but instead saves the password for later use, then yes, if you change the password before he uses it, that will help.
http://www.geoffreylandis.com
I think this might be poor advice for any system that does not block and report after failed attempts. Yes, if your password is a 4-digit number it could be cracked in 10,000 attempts OR LESS. Obviously would not take that long if you can make unlimited attempts AND thousands of attempts per second. Most crackers can do all numbers up to 4 digits very quickly indeed for windows passwords (see ophcrack reference above) and if I remember there are things like john the ripper for unix hashes...
If an attacker gains access to brute force any system then the time taken to brute force with only 4 numeric digits might be miniscule. For instance, think of a 4-digit combination bicycle lock. I can physically crack one of those quite quickly. Its not that different. I once cracked a fairly complex 8-digit password in under a day (I felt that was lucky though). If you can get physical access to a machine (or can socially engineer someone who has) there are usually workarounds that will bypass password mechanisms anyhow (there certainly are for Windows). My current password scheme is to use 'up and down the keyboard' pattern sets with mixed case. i.e. zse45TGB and then shift along a set every 90 days so next block is xdr56YHN. Handy if you don't access a system for a few months/years and can just go back. Even using these unpredictable non-dictionary patterns you're not safe from the brute force rainbow tables which just store every hashed result like a dictionary database. Time is the only thing a good cracker needs, Moore's Law will fill in the gaps.
With the worries of security I'm shocked at the number of people that use 4 digits for a bank PIN. Mine varies between 10 to 14 digits. Yes I change it every-so-often. I believe the limit on Plus / Interac compatible banks is 16 digits.
I used to work at a coffeeshop and at least 85% of the customers used a 4 digit pin. I know this because the pad went BLEEP for every key push. Just count the bleeps.
Are you serious? All it takes is 3 attempts to lock someone out for 5 minutes? Sweet! There's this guy named khasim on this message board that really pisses me off. I think I'll just set up a little script to periodically log in with bogus credentials...
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 why it takes longer to break a 7 character password than an 8 character password.
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
The risk of this type policy (in a corporate IT environment) is that you start locking people out during important sales presentations, during middle-of-the-night production emergencies, during shareholder meetings, and during critical moments of new project go-lives. In an e-commerce environment, obviously, the risk is that you'll drive away customers who can't use your system.
My (large, important) company has a 10-password lockout backed up by a 24/7 1-800 number with an automated system for resetting passwords. Even that's a pain sometime... in the real world people futz up passwords repeatedly because they put their fingers in the wrong place, have the caps lock on, have the wrong keyboard layout selected (dvorak--my personal password beast), or are struggling to remember the new password they chose.
Why? As others have pointed out, it's not part of the security mechanism. Go ahead and tell the user their account is locked and point them in the right direction. For e-commerce especially... your users have umpteen different logins that they rarely use, and they need some help recalling their username on your site.
-1, Too Many Layers Of Abstraction
I read a persuasive article once that argued that writing down passwords was a good thing. The argument was that this allows the user to select stronger passwords without worrying about forgetting them.
In essence, you replace an IT security problem with a physical security problem. The number of people with physical access to your desk, or wallet, or whatever is probably considerably smaller than the number of people with electronic access to hack your account.
Enjoy life! This is not a dress rehearsal.
Are you serious? All it takes is 3 attempts to lock someone out for 5 minutes? Sweet! There's this guy named khasim on this message board that really pisses me off. I think I'll just set up a little script to periodically log in with bogus credentials...
Do you really prefer the alternative? That anyone can set up a script with an unlimited amount of guesses on your* password?
*No, not your password, which is strong. Your users passwords', which often takes the form "John" or (if you're lucky) "Johnathan45".
I lost my sig.
No, it isn't that simple.
It is that simple: don't provide any information to a potential cracker other than that an attempt either succeeded or failed.
Imagine this response from a web site: "You attempted to sign in with username joe.blog@somemail.com, but unfortunately there is no such user registered. Please make use of this opportunity to register now."
Or this: "You attempted to sign in with the valid registered username joe.blog@somemail.com, but unfortunately you submitted an incorrect password. Silly person - please try again."
Both (contrived) responses indicate whether or not there is such a user currently registered on the site. That's too much information and entirely unnecessary.
Forgot your username? Tough.
Does that excel sheet also calculate the number of additional help desk calls and wasted work time of password resets that stem from changing passwords too often and using too complex passwords for people to remember? Also, making these recovery methods an everyday practice makes other kinds of cracking methods (such as social engineering) easier, thus reducing the gained "level of security".
If it wasn't so, everyone would naturally use 128-character totally random generated passwords that must be reset after every use...
Except many email addresses are public because they are used as a method of contact which, if you like bringing in new customers, is important. Of course, this might not be necessary for most people in a large organization - unless they do things like volunteer, fundraise, coach little league, etc.
Reading code is like reading the dictionary - you have to read half of it before you can go back and understand it.
If the cars are moving, the probability of each individual shot hitting is the same as before eg 1:10, but the probability of one of the series of 10 shots is less than 1:1. However the probability of more than one of the 10 shots hitting has increased from 0:1.
If what matters is whether or not you are shot rather than how many times you are shot if you are unlucky, then you should move around.
When we had the opportunity to rebuild our network from the ground up, my boss insisted that the usernames be different from the email addresses for security reasons. No amount of talking to him would convince him this was entirely unnecessary as account lockouts would protect from password guessing bots. It's not an issue most of the time, but it is added confusion for users, and when it is an issue it is a real pain.
I just can't resist adding that it is really easy for us to enforce password policy for all services domain-wide by a simple policy setting on our DC. In our cluster computing group, where Linux boxen are the norm, chaos reigns and it is a really good thing that those machines are not accessible from the external network.
If only there were some centralised directory protocol that could be used with Linux to enforce password policy amongst different machines. Ideally it should be lightweight. Just one more area where Linux needs to catch up with Windows. If only we had Group Policy too, so that we could manage systems remotely.