Calculating Password Policy Strength Vs. Cracking 231
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."
Is this a problem? (Score:5, Insightful)
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.
Re: (Score:2, Insightful)
The focus should be on the account. (Score:5, Insightful)
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.
Re:The focus should be on the account. (Score:5, Insightful)
What happens when a bot comes out whose sole purpose is to discover all usernames on a system (including the admin users), via dictionary attack, common variations, and lock them all out, by making exactly 3 attempts per account?
i.e. Hackers whose goal in life is to disrupt access to the system rather than to break in.
Re: (Score:3, Insightful)
You switch to physical tokens?
For the most part, if you are protecting something valuable, you will be willing to spend more resources than someone just trying to be a nuisance. That doesn't make them any less of a nuisance, but it isn't particularly hard to work around them.
I guess this sort of sucks for someone trying to run a small forum or something, but they could do something crazy like support OpenID.
The same thing that happens with everything else. (Score:5, Informative)
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.
Re: (Score:2, Insightful)
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
Re: (Score:3)
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
Re:The focus should be on the account. (Score:4, Informative)
i.e. Hackers whose goal in life is to disrupt access to the system rather than to break in.
Those type of hackers are rare and have less resources. There isn't any point in pure vandalism you see. In any case research has shown that it's not a primary motive.
http://www.aic.gov.au/publications/htcb/htcb006.html [aic.gov.au]
Re: (Score:2, Interesting)
Those type of hackers are rare and have less resources. There isn't any point in pure vandalism you see. In any case research has shown that it's not a primary motive.
Pure destruction without personal gain has its uses. See DOS attacks, pretty much every army in existence, terrorists, blackmailers, etc.
Re: (Score:2)
Yes, this does allow for DoS attacks. So what?
This attitude is not really welcome among the users, you know. Compare the Linux login method: on a password failure, a 3 second waiting period is enforced before you can try again. After three strikes, 15 min lockout. 12/hour/host is way too slow for a good password, even with, say, 1 million attacking hosts.
Re: (Score:2)
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?
so they can prevent everyone from logging-in. would that not cause a problem to your login system?
Comment removed (Score:5, Informative)
Re: (Score:2)
Your better off throttling an account at (12/min 5s between guesses) it takes more than a year to get an 8 digit even a 7 digit password will be safe for 120days. Although your still vulnerable to bots that don't care what account they get if they just want an account, for that you need anti-bot net stuff
*if the same IP gets x wrong passwords in y hrs (irrespective of accounts) put them on a blocklist for 24hrs, if they get a 10 wrong the following day put them straight back on at 0.007attempts/min they 10,
Re: (Score:2, Interesting)
Unfortunately it's not the gathering of the passwords that hurts the business with things like Confiker.
I was recently on contract for a large bank doing what they called "lvl 1 support" (tough times and no work calls for tough measures). I bailed after 2 days due to the fact they'd let Confiker take a massive hold on the network. 1500+ servers, every workstation of about 20 000 was infected. The biggest issue was that users were being locked out of their accounts, productivity was at almost 0, and the high
Re: (Score:3, Insightful)
Frequency of change is irrelevant! (Score:3, Insightful)
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 inte
Re:Frequency of change is irrelevant! (Score:4, Insightful)
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.
Re: (Score:3, Informative)
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.
that implies that the password hacker has a mean to ascertain if a password he tried was a "near miss", i.e."congratulations! you got X characters right but on the wrong place, and Y characters right and in the right place. Try again? Y/N". BTW, Mastermind anyone?
Here in italy the security model approved by the law is : 8 char password, change every 90 days. I agree that changing passwords, or even forcing user to use password that are totally different from those previously used, is futile if you do not
Re: (Score:2)
No it doesn't imply that at all.
For each password you try, you have for example 1:1x10^111 probability that it is correct.
Without a password change as you go through your 1x10^111 possible combinations, you will find the correct one eventually.
This is the same as a situation where the password is a single bit. A brute force attack would take two attempts, and where changing the password includes the possibility of keeping it the same as before.
If the password is changed once while you go though them all, y
Re: (Score:2)
The thing about changing passwords is that is that it is not intended as a measure against bruit force attacks. You change them so that leaks get plugged.
User A gives user B his/her password despite that being against policy for reason X. At least a few months later user B no longer knows A's password. Suppose user B leaves the company or something IT naturally disables B's account and does not disable A's account. Its a good thing B no longer has A's credentials.
Password changes are a weak but probably
Re: (Score:3, Insightful)
and even if you do, you don't have long before you have to run the attack again.
Not really. Because if people need to change their passwords frequently, they tend to go for stupid changes, such as incrementing a suffix number. I could make a pretty good guess of what some passwords on our systems will be a year from now, even though they are nominally changed every 90 days.
Re:Frequency of change is irrelevant! (Score:5, Insightful)
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.
Re:Frequency of change is irrelevant! (Score:5, Insightful)
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.
Re: (Score:2)
It is all pretty irrelevant though since I dont know many systems that let you keep making authentication attempts anywhere near 65 tries a minutes. I can maybe think of so
Re:Frequency of change is irrelevant! (Score:4, Insightful)
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.
Re: (Score:2)
65 guesses per minute? (Score:2)
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 [lockdown.co.uk] 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 passwo
Wrong threat (Score:5, Interesting)
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).
Re: (Score:2)
Hang on... A little maths: (Score:2, Interesting)
Re: (Score:2)
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.
But most systems only apply this policy per account.
If you have 300 known usernames you can try another username/password pair every second and never test one account more than once per five minutes.
Re: (Score:2)
Re:Is this a problem? (Score:4, Insightful)
Anyways we can crack the passwords in a couple hours or less from the password hash on a workstation.
If it's taking you "a couple hours" to crack a Windows password that meets the criteria you specified, you're using the wrong tool. Have a look at Ophcrack [sourceforge.net], then see if you ever want to use a less-than-15-character password on a Windows system again.
Re: (Score:2)
Re: (Score:2)
Cracking with a hash is a lot faster than cracking without one.
I'm still confused by the math:
(90 days) / (8 ** 94) = 1.0006852 x 10^-78 seconds
For reference, Planck time is 5.39124*10^-44 seconds.
Where does the 65 passwords per minute come from? Even if we assume many, many, users, you still need to provide the correct username/password pair.
I was under the impression that the mass ssh password bots that hit our cluster constantly are looking for weak passwords, not trying to break reasonable ones.
That sai
Re: (Score:2)
Re: (Score:2)
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.
You're missing the point. This isn't so much about guessing the password in network logon attempts as it is about guessing passwords on already-compromised machines. Since users frequently use the same password on multiple systems, a password file from a compromised workstation will sometimes yield valid passwords for other not-yet-compromised systems. Local passwords can also be useful in decrypting hard drive contents in cases where the encryption key is stored locally, wrapped with the user's password.
Of course, its not that simple... (Score:5, Informative)
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?
Re: (Score:3, Interesting)
"Others will lock you out after 3-5 attempts."
Yeah, I know the type. They are for people who are truly paranoid about break-ins, and incredibly unconcerned about denial of service attacks.
Re: (Score:2)
Clearly the only solution is to let the attackers keep hammering away without any countermeasures.
No, really, I mean it. What you do is force everybody to have a 5-10 sec delay on login. Immediately, your hacker's ability to bruteforce your system drops by at least an order of magnitude.
Re: (Score:2)
But as we saw from the Sarah Palin debacle last year no complex methods are needed if you know a few personal details about the user like their mother's maiden name or their first pet.
Re: (Score:2)
If you don't have a "3-strikes" policy, you can be hit with a DOS.
Not when you there's an enforced delay of, say, 5 seconds after a bad attempt.
Re:Of course, its not that simple... (Score:5, Interesting)
Still don't get it? Ok, I'll try again, with a real world example of how stupid sysadmins can be.
To get unemployment benefits in Norway, you have to fill out a lot of paperwork every 14 days.
Fortunately, this can be done online.
Unfortunately, if some idiot has your username, and tries to guess your password three times, the account locks completely for 30 minutes.
So there you have it. For three connections every 30 minutes, you can make sure an unemployed Norwegian won't eat the next two weeks. Cute, eh?
There are denial of service attacks, and there are denial of service attacks. Sometimes you need a botnet of thousands of machines. Sometimes you need one machine, a perl script and insignificant bandwith. The latter is a bit more aggravating.
Re: (Score:2)
Like all Unix-based systems, for example.
Re: (Score:2)
Well, like pretty much all current operating systems, really. Unless I did something without realising it, if I type the wrong login name in Windows, it doesn't tell me instantly.
Re: (Score:2)
Re: (Score:2)
Can you imagine what would happen if this were to happen on a Monday morning at 9:00am, right before trading opened on Wall St, for any number of large financial companies?
While not every detail is clear to me, I can imagine that it would definitely involve you losing your job in the middle of a recession with damn little hope of getting a new one. I would not count on the corporate spyware and tripwires from not catching you do it either.
In short, being a dick is easy, but it is also very stupid. Why not use your time to do something productive instead?
Re: (Score:2)
I would suppose it would depend on the number of puts you have on Firm X in an offshore shell company as to how productive destroying the company is.
Your odds of facing consequences decline the more negative the banks net worth is. (as long as you are up enough that you can give back 100,000,000 or so from you gains.)
Yeah right (Score:5, Insightful)
Re:Yeah right (Score:4, Insightful)
How many of us use truly random passwords?
Consider the dictionary attack, combined with numbers, symbols and other words, and it's really not quite so random.
Re: (Score:3)
Re: (Score:3, Insightful)
Anyway, it usually takes one or two phone/support calls to bypass a password.
People make it even easier nowadays:
Mother's maiden name?
Where was your father born?
The trouble with such stupid questions is it makes it harder for those who know what they are doing. The sheeple will just cheerfully give their passwords away to the next person who asks or for a free beer.
Re: (Score:2)
The trouble with such stupid questions
Funny how the old saying 'there are no stupid questions, only stupid answers' actually applies to this.
To avoid the potential trouble, simply don't make a habit of specifying the correct answer; there's usually nothing preventing you from saying your mothers maiden name was Thevirginmary, or claiming that your father was born on Krypton.
Of course, it may get a bit more difficult to remember, but it'd prevent anyone from simply researching the answer to your hints.
Easy to remember false answers. (Score:3, Interesting)
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.
Re: (Score:2)
I'm really lucky that my mother's maiden name is a 64 byte sequence of random hex, as was my father's city of birth. And even more lucky that it's different depending on who is asking.
The only services I use still vulnerable to that attack are my financial ones. It sucks, I know, but they force you to do it, and I haven't been able to convince them not to.
It's sad. We have these passwords which provide some security at least, and then we throw it all away and force users NOT to be secure.
Re: (Score:2)
I'm guessing you are typing it from a keyboard, so it is not truly random after all.
Re: (Score:2)
Her parents named her after some output from a tRNG. Short of gvmt organizations who can get in anyway, I'm sure, I don't think anyone's breaking in.
I'm not trying to stop a determined attacker. I'm trying to stop the mass harvesters.
Re: (Score:3, Informative)
Re: (Score:2)
and other sneaky tricks...
You mean something like that [xkcd.com]?
Re: (Score:2)
A network based attack, is however, an entirely different story.
Re: (Score:3, Interesting)
6 lower case + 1 upper case + 1 symbol/num is the norm meaning it only takes roughly 26^8 * 6 (assuming the 6 lower case letters are together) / 2 to crack via brute force
this gives 6.26481e+11 or 80566 attempts/second for 90 days, which is still tough but much more achievable than assuming your 96^8 guesses are needed
Re: (Score:3, Informative)
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
Re: (Score:2, Insightful)
This whole new password every 90 days things blows monkey chunks too. All it does is make me have a half a dozen passwords or more likely variations on a few passwords that I never know which one belongs where and end up putting every valid password into all the wrong sites.
If the password is strong to begin with then changing it every 90 days is stupid. Who's to say the password I change it to isn't next on the list to be guessed?
Monitor systems for strange access, restrict my access to just what I need,
Re: (Score:2)
I'd love to see your modern processor which can perform all the generation, communication and validation required to attempt a single password in 1 clock cycle.
Apologies.
Re: (Score:2)
Under the radar (Score:4, Insightful)
And 65 guesses per minute is hardly something that should trip ANY rule of an IDS.
quick slashdot reader test: (Score:4, Interesting)
Re:quick slashdot reader test: (Score:5, Funny)
This really just moves the test up a step (Score:2)
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. ;)
Re: (Score:2)
Is it...
Nah, it couldn't be...
Is it "hunter2"?
Missing part of his formula (Score:5, Insightful)
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?
Re: (Score:2)
I tend to pick "random string" type passwords, write them down and stick them to my computer case.
If someone has successfully gained physical access to my machine, it doesn't really matter how strong my passwords are anymore. I'd rather have the (easier) problem of phyiscal security to solve than the harder problems of adequately securing using weak passwords or trying to remember strong ones.
Re: (Score:2)
It kindda still matters. If I'm at the office, and stick my password on my box...well, yeah, everyone has physical access to my machine...but SOMEONE will notice when the receptionist is taking a screwdriver to my workstation. They won't notice her picking a post-it note from it.
Re: (Score:2)
> It kindda still matters.
In your case, yes. In others (locked offices) it may not.
> They won't notice her picking a post-it note from it.
You would probably notice her picking a slip of paper from your wallet.
Re: (Score:2)
That's why I camouflage the password. It's not a post-it with "Password: aa\x5Ahf". But something like:
"""
TODO:
- fix bug http://is.gd/av+a3ohW [is.gd]
- file header should be: aa\x5Ahf
- upgrade http://tinyurl.com/ov-eiP2o [tinyurl.com]
"""
Re: (Score:2)
Re: (Score:2)
I tend to pick "random string" type passwords, write them down and stick them to my computer case.
Why not use a passphrase instead? Even without special characters, no one is ever going to crack one of my 20-to-40 character passwords, unless they've built a custom cracking dictionary filled with every possible combination of lines from films/novels and song lyrics. Since we have a "must include upper/lowercase, a number, and a punctuation mark" policy at work, it would require many, many more variations eve
Re: (Score:2)
> People will increase risk by having to write them down...
Depending on your threat model that may not be a risk. You are generally much safer letting your users carry truly random passwords in their wallets than letting them use their pet's names.
Measuring complexity? (Score:5, Interesting)
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.
Re:Missing part of his formula (Score:4, Interesting)
Years ago, the Air Force had some pretty ridiculous security policies for its I.T. systems. (And I would expect that they still probably do.) I've written extensively here on Slashdot about them, but one thing that consistently bugged me was the password policy. I can't recall the specifics, but the password had several "conditions" that needed to be satisfied before it would save your password. Among them were things like:
- Must be mixed-case
- Must be between 8 and 12 characters in length (or so)
- Must contain at least 2 symbols (barring a short list of seemingly random exceptions)
- Must contain at least 1 letter
- Must not contain a space, tab, or non-keyboard character
- No part can match a dictionary word or proper name
I'm not a cryptologist, so I always wondered: wouldn't adding so many restrictions actually make it easier to brute-force passwords? If an attacker knows the unit's password policy, shouldn't that enable them to narrow the search space considerably?
Our problem (Score:2, Interesting)
hmm... (Score:3, Interesting)
Re: (Score:3, Insightful)
Security Tokens/Smart Cards... Two (or Three) factor authentication is superior to username/password. Something you HAVE + Something you KNOW. If you dont have both then knowing soandso's password is hunter2 wont help you.
Required Passord Changes (Score:4, Insightful)
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!
Re: (Score:2)
physical access is ownership. that problem doesn't have a solution.
So don't allow password authentication (Score:3, Insightful)
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.
WOW, what a GREAT social engineering! (Score:2, Insightful)
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!
Re: (Score:2)
...when you can simply open a site, offer them to "check them for security", and let them input them themselves!
It's not a website; it's a downloadable spreadsheet. It does not ask you to input passwords, but rather the parameters defined by your password policy. For example, the length, number of possible characters, and number of days between password changes.
Password strength is meaningless. (Score:2)
Re: (Score:2)
A four letter password is still stronger protection than most people give.
It isn't depending on the system. If you're working with Windows, passwords less than 15 characters in length can be cracked in a trivial amount of time (usually minutes) using a rainbow table-based system like Ophcrack, assuming access to the hash.
Some ways to obtain the hashes for privileged accounts:
1 - From the local cache on a workstation (e.g. the service accounts used for remote software installation).
2 - Intercepted off of the
Re: (Score:2)
Re: (Score:2)
According to this spreadsheet, it'd take millenia to guess my best password.
But I suspect my password will be cracked by more advanced computers long before then. Or a keylogger will get me. Or I'll die of old age.
It's about 40-50 characters long before adding a passphrase to the end. It's not written down anywhere, either on paper or digitally. Like a true geek, I remember the whole thing in my head.
And no, I don't use this password on Slashdot. This is my special "only if it's direly important" password.
Re: (Score:2)
The math is wrong (Score:2)
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
Bullshit (Score:2)
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: Wh
The Myth Of Strong Passwords (Score:2, Troll)
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 pass
Re: (Score:2)
Come on, if Roger Grimes had ready access to beer and/or women he wouldn't be writing for InfoWorld.
New online service! (Score:2)
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 tha
Evaluating password strength (Score:2)
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.