Real Security? 557
An anonymous reader writes "A recent article at Ask Tog raised the common argument about how much security is good. Tog says: 'I've been watching security people for years as they've slowly increased the security of everything they can get their hands on until any idiot can wander in.' Is this the case? Are we increasing security too much, so that the users circumvent it? Should we be allowing simple passwords?"
Definitely (Score:4, Interesting)
Wait a second (Score:2, Interesting)
Two minds about it (Score:5, Interesting)
As a sysadmin, though, I feel longer passwords are better. If systems supported it, I'd require medium-long sentences for passwords. A full sentence is fairly easy to remember, but not very vulnerable to a dictionary attack.
I disagree with the article (Score:3, Interesting)
Annoying security leads to circumvention (Score:5, Interesting)
So a simple ssh tunnel into a work machine, and a modified transparent proxy setup(I had the GPL'ed source), and an iptables rule, and wow the webmail server always thinks i'm inside the firewall.
so while i'm doing the forward securely with ssh, they just annoyed me and i worked around it.
Maybe no security at all (Score:5, Interesting)
So I guess, the software equivalent of that would be to not leave expensive data that could interest people on networked box, and make as much as your sensitive data as possible less sensitive, by simply publishing it. GPL code, for example, doesn't have to be protected.
I'm not saying everything should be released, far from it, but there's a lot of "hidden" data that could just be left readable by everybody, by changing some company policies and being a tad more open about everything, thus removing the desire/need to hack the box it's hosted on.
passwords (Score:5, Interesting)
I have developed a password that I use on systems I can control that consists of 13 characters, both letters and numbers, and a & sign in for good measure. It makes perfect sense to me, I will NEVER forget this password, and you would litterally have to be able to read my mind in order to guess it. But most systems wont accept it for whatever reason or another, so I vary it slightly to conform to whatever rules are in effect. This creates a problem of about 5 variations of what I want my password to be.
I think people need to be educated on how to make a strong password. It should be up to the user to provide a strong enough password, because if the user can't remember it, then the entire process is pointless. We're supposed to show photo id at school to have our password retrieved for us, but it happens so often, that the people behind the counter just do it. How many other places do this same thing, because EVERYONE forgets their password?
Sorry for the long rant, but I felt the need to get all this off my chest
Passwords in linux (Score:4, Interesting)
(UP UP DOWN DOWN LEFT RIGHT LEFT RIGHT A B A B) anyone?
Myth... (Score:4, Interesting)
Does enforcement matter? I'd be lying if I said it didn't. However, the means in which it is dispensed is the issue. No one enforces a security policy? Don't be surprised when a stranger walks in the door. People enforce security like a police state? Don't be surprised when people in power abuse their abilities and allow their friends to skate around issues. Then, of course, there is the typical knee-jerk reaction when an event happens and everything is locked down to only be forgotten about two months later.
Use common sense, as it isn't common to most people. Tailor the security to the individual company; a meat processor protects their beef, Lockheed Martin protects missile technology--each is deadly in different ways.
Re:The greatest threat... (Score:5, Interesting)
My company now wants to deploy these magical devices to all employee computers and can't figure out what I mean when I say they'll make things less secure. I think this article was dead-on.
TW
Not the source, really (Score:5, Interesting)
The guy in the basement office has about as much control over this process as Pvt. Beetle Bailey does over the war in Iraq.
And really - would those same people who tape the password to the monitor tape their garage door key to the doorframe because "it is too much trouble to carry 3 keys around"? I have 15 keys on my keyring, personally, yet no one makes offensive statements about architects and locksmiths re: "door design".
sPh
Re:Common Sense (Score:5, Interesting)
I recently got into an argument with the head of the security program at the university I'm attending over a similar situation.
When resetting my password, which was not expired, I was required to go through a 20 minute online "security training" seminar. It was only 10 questions, but the site was so incredibly slow that clicking through the 10 questions (about 3 pages per question) took 20 minutes. The questions covered the basics of security (don't give out your password, etc.). Two of the "correct" answers were technically wrong.
After expressing my displeasure with the questionnaire and pointing out the technical problems, the administrator chastised me for "not thinking that security education was a good idea." I pointed out that I thought it was necessary, only he did a poor job of it. He missed the same thing that several security programs miss when educating the users:
Security training is useless if the user ignores it.
I was going to add is annoyed by it, but I can think of one security awareness activity that pissed off several people, but was highly effective.
After weeks of notifications about laptops needing to be secured when not attended (i.e. overnight), we went on a laptop finding mission. Any person that left a laptop not physically secured to his/her desk came in the next morning to find a slip of paper telling them where they could claim their laptop. Several people were very upset, but also remembered to lock up their laptops before leaving.
Re:Definitely (Score:5, Interesting)
I have a three tier password system, with passwords "expiring" every 30 days.
Tier 1 passwords are things like root passwords for systems. These are 100% unique to the server they belong to, and are changed without fail.
Tier 2 passwords are passphrases for my ssh keys for non priviliged accounts. These are the same for 2 or 3 boxes, and again change every 30 days. When I expire tier 1 passwords, they are sometimes moved down to tier 2 for ease of remembrance, tho never for the same servers.
Tier 3 passwords are for websites, like this one. Usually most of my website accounts share the same login details, as Im not really bothered if someone logged onto slashdot and stated that im a gay faggot or whatever. Tier 2 passwords are usually passed on when they expire.
I tend to treat passwords as something like special email addresses. You rarely forget an email address because its in a known format: something @ something . something. So therefor I base my passwords on a similar format, one that I can remember or work out, eg AAAA!AA.AA@A# gives me a more memorable password than #@##23$ssDx_ which would be an excellent password except for the fact that it sucks
Re:The greatest threat... (Score:2, Interesting)
The wetware is always the weakest link because it is the hardest to patch.
Re:Definitely (Score:5, Interesting)
I do. :-)
The funny thing is, I don't actually remember the character sequence. Maybe it's because I play the piano, but I remember the hand motions of typing the password. So to pick a password I just generate a few random ones until I find one that "feels" okay.
I wonder how many people do this too
Re:The greatest threat... (Score:5, Interesting)
People have a limited memory. They generally remember three or four passwords. Deal with it. Either use biometrics, or a password culled from a sentence (as another poster suggested). Or do a dictionary attack on all user's passwords at signup time, and refuse anything in the OED. Or use one of those nifty word verification challenge-response things that are all the rage in web-facing pages.
People don't change their passwords. Deal with it. Either they're going to write them all down somewhere, or they're going to memorize them. If they write them down, they're succeptable to attack. If you force them to change their passwords, they can't be memorized. But if they are memorized, they can't be compromised with any method that would otherwise catch any login.
And yes, any network can be compromised. You have to reduce the risk, but you also have to work with the way that people work. I worked at a place with randomly generated 8 character ascii passwords. For security's sake, the password system was case-sensitive. For simplicity's sake, the passwords generated were all upper-case. Invariably, new hires were given the password as lower-case (which makes sense to us humans), and then wondered for weeks why it wasn't working yet.
I use a password storage system with 256 blowfish encryption, but the idea that I have to store passwords in a password-protected system is a little scary.
Security is the human factor. How do you give access to one person and not another? How do you verify identity? What can't be faked and / or given away? If by social engineering you mean sneaking into someone's job pretending to be the plant waterer, then stealing the password they have taped to their monitor, then yes, social engineering is part of being a l33t h4x0r. Mitnick's greatest exploits generally involved pretending to be one person to gain enough access to pretend to be another.
Your password has been reset to "Duh" (Score:3, Interesting)
To get your login, a representative of the IT department gave you a sealed envelope in person. Your manager was not allowed to receive it on your behalf under any circumstances.
To reset your password to the current day of the week, however, all you had to do was ring the helpdesk and say "I've forgotten my password, and my name is..."
There's resistence to changing this approach 'cos the complex password requirement and the enforced 30 day password expiration result in multiple daily requests for this.
Nicely illustrates the point, I think.
Re:Definitely (Score:3, Interesting)
ssh keys + long passphrase (Score:3, Interesting)
As a security feature at work, we've started switching our more important boxes to key-only login. I've done the same to my boxes at home, for good measure. Now, I have 2 keys. One that lives on my box at home, and one at work. They don't exist anywhere else (other than a USB pen drive for backup), and will never be copied off of these drives. I use a relatively long passphrase (19 chars), but since I use ssh agents (and agent forwarding when it's safe enough to do so), I only ever have to type the passphrase once per day (the machine is set to forget the passphrase when I leave work).
Now if only all of those ecommerce type places would work with my public keys...
Re:Not the source, really (Score:5, Interesting)
Rotating passwords...heh (Score:2, Interesting)
So, whenever I am faced with the now dreaded "Please type a new password" prompt, I transpose two letters in my current password, then after entering the site, go back and change my password back.
A pain in the ass, and just gets me annoyed with my bank, I don't feel anymore secure with a new password than the old. So why change it? And for that matter, if they are forcing me to change my password, why let me change it back immediately?
My experiences (Score:3, Interesting)
I believe in letting the user select their own password, but to a point. Meaning I don't let them do smith1 or johnsmith1. Something *they* can remember. To me, if the user can remember it, it means its not printed anywhere on the workstation or desk.
Re:Definitely (Score:2, Interesting)
Re:Common Sense (Score:4, Interesting)
I had a similar experience at the Community College where I teach. After the Sobig, Blaster, etc. attacks of a few months ago, they (Information Technology) installed a McAfee program called "Stinger", which runs every time a user logs into the network, and (apparently) scans the hard drive for virus infected files.
Takes 10-12 minutes to run.
Classes are 50 minutes long.
Stinger responds to the STOP button
---> Illusion of Security!!!
Re:Definitely (Score:3, Interesting)
I take something easy, like a dictionary word.
and offset all my letters.
so "monkey"
becomes "k0jo47"
Also I shift the first 3 letters/numbers
it becomes very reflexive bu is also easy to remember as a dicionary word.
Possible? (Score:1, Interesting)
1 - Method of selecting a number between 1 & 16
2 - 16*64bytes programmable flash memory
3 - 1 button
Now, I program in all my 64 character passwords (16 of 'em), and when I sit down at any computer, I just select the password I want on the DIP Switches or whatever, press the button, and its sent in through USB as if typed on a keyboard.
If you integrate this with a 'proper' USB Key, too, it gives you a pretty tight security solution. Assuming your computers don't have software keyloggers, and you don't get mugged...
Good methods (Score:3, Interesting)
"apt-get install pwgen [sourceforge.net]" for a program that can produce (among other things) pronouncable passwords.
Or grab some dice and go to: Diceware [diceware.com].
Password Algorithms (Score:3, Interesting)
(Posting as AC to prevent someone from guessing my real algorithm.)
I'd like to suggest a method for creating passwords for sites; I'm sure it's not unique to me, but it's effective, more secure than sticky notes, and not very time-consuming.
The technique is to use a simple algorithm to create the password, seeding it with a unique identifier from the location where the password is to be used. This way, you can remember the algorithm (even write most of it down if you like) and yet the password for each site is unique, and if stolen doesn't give the intruder access to any other site. (If your algorithm is good, it would make it hard for someone given 2 or 3 of your passwords to figure it out.)
For example with a site named "acmewidgets.com" my algorithm (modified) is:
My actual algorithm makes it a little harder to see english words in the final, but like the above produces a 8-character password (often one of the boundaries for password limits, e.g. 2-8 characters or 8-15 characters) with both mixed case and digits. It is almost always valid for password security checkers, and (in my opinion) is reasonably secure. And yet I never have to remember my password for various sites, I just recreate it on the fly.
And almost always, if a site is used often, even the complex-looking password it creates is not hard to memorize through the use of mnemonics. (The human mind is a wonderful thing.)
The above algorithm doesn't allow variations for more/less secure sites, or backups when passwords expire. (I hate expiring passwords. If the account is compromised, it's compromised...expiring the account every 6 weeks doesn't undo the damage.)
If it can be made, it can be broken (Score:3, Interesting)
Security is like Oxygen.
Some is better than none.
Too much and things tend to go up in flames.
Enough security that users do their best to ignore/circumvent it is counter productive
Most people forget CryptoGnomes "Golden Rules of Security":
One day, your security will be compromised.
More than likely, sooner than you think.
Almost certainly in some way you did not (perhaps even could not, reasonably) have expected.
What will you do then?
I'm sure you've all heard it said before security is a process, not a goal. The best you can ever hope to do, is make it harder for someone to breach your security than they think it's worth, and to have a plan for when someone comes along who thinks no effort is too much.
Either that or drop all your computers and networks into a large vat of suitably potent acid, and take up a new career; like basket-weaving.
Password Safe (Score:5, Interesting)
The password db is blowfish encrypted (yes, there are some cracking programs out there for it, but I'm not trying to keep the info from the NSA). Only two requirements: 1) don't forget the main password, 2) backup the Password Safe db to multiple places.
The only passwords I remember now are my ATM PIN number, the Password Safe pwd, and that single pwd that I use for every web site that demands registration to function (where I use a fake name as well).
Re:Annoying security leads to circumvention (Score:3, Interesting)
You sure did. You worked around it by creating a secure tunnel to just your home. I'd say that's quite a bit more secure than the RSA key. Which you have to admit, isn't really DEFEATING the security
Interesting, though, how much work you had to do to get around it, and you KNOW the system. A hacker would have to be pretty fucking determined to to what you did, and pretty sneaky not to get caught doing it.
Re:Annoying security leads to circumvention (Score:3, Interesting)
Even if ssh is unbreakable, your company's overall security has been reduced. The physical security of your home is probably worse than the office, but now an attacker can burgle your house to reach corporate-wide data.
Of course, if you're allowed to ssh into work, then that vulnerability exists anyhow. But if the workplace blocks inbound ssh and you created the tunnel in the reverse direction, then the danger is your own.
Re:My personal favorite (Score:2, Interesting)
Authentication systems typically rely on three things: Something you are, something you know, something you have. Password authentication is weak in that it only uses one of these three. But when it comes down to it, who cares if the secret is the algorithm you use to pick your pass phrase instead of the pass phrase itself?
Diceware! (Score:3, Interesting)
Basically, you take a list of words indexed by all possible rolls of 5 dice, 11111 through 66666. You roll 5 dice and pick a word, and repeat to desired password length, eg
cleft cam synod lacy yr
Sure, your password is longer this way, but you can memorize it easily and type it quite fast as it is a series of English words.
For my secure passwords, like PGP keys or banking, I use diceware, 7 words. This is some 85-90 bits of entropy and pretty much unbreakable for the forseeable future. For account passwords I use 3-4 words, which is enough that a database thief will break someone else's login first. For crypt shell accounts, I use mixed-case alphanumerics (similarly, about 48 bits of entropy). This adds up to under 10 good passwords to remember, and I don't change them often (no good changing a PGP password anyway, and I only change shell passwords occasionally).
For most websites (/.), I use a family of very weak passwords (a couple random words and symbols, but varies little from account to account), as I don't care much if you hack here and post in my name.
All these are in a heavily backed-up text file in case I forget them, encrypted with my PGP key.
my password scheme (Score:2, Interesting)
- the different sites/accounts have different policies for what a "strong password" is and how often you are forced to change it
- some accounts are more trustworthy than others (your bank will never reveal your PIN... but some random website--slashdot for example--might be hacked and your password might be vulnerable)
- different levels of security are used to protect the different passwords.
So I use the following simple rules:
(1) build all my passwords out of two or three 'building blocks' of random alphanumeric characters.
(2) When changing a password, I change at least one block and leave at least one block the same as it was before.
(3) I mentally assign each account to one of three categories: 'important' (bank PINs and other uses where security is crucial), 'somewhat important' (various work-related passwords, etc) and 'unimportant' (internet e-mail, web sites where I don't use a credit card, etc).
(4) NEVER use a password in more than one category.
(5) EVERY 'important' account must have a UNIQUE password that I don't use for anything else. Some 'important' accounts will allow very long passwords; I have a few that are >20 characters long.
(6) NEVER write down an 'important' password anywhere, unless the loss of the password would be unrecoverable.
(7) Change 'important' passwords every month or two, and 'somewhat important' passwords every 3 or 4 months or so.
(8) 'somewhat important' accounts may use the same password as other 'somewhat important' accounts with a similar purpose (all work accounts, for example). 'unimportant' passwords can all be the same, unless I particularly don't trust the security of the site in which case I usually vary one of the blocks.
I have had good success with this strategy (remembering the 'blocks' is similar to remembering telephone numbers... so remembering a password is like remembering telephone numbers. N.B: *don't actually use* telephone numbers =P)
simply wrong (Score:1, Interesting)
As stated in "secrets and lies", computers were much more convienant before the use of passwords at all.
Passwords are the least cost authentication method, and at the same time the most highly attacked method. In general if the budget can afford it, a stronger form of authentication is used. Most every security person understands
that passwords simply do not scale.
Perhaps random phrase based passwords whould be easier for your users to remember (like most OTP tools generate).
Or even better go to a key/x.509 based system, so users only have to remember one strong password.
There is a much lower cost to this than a hardware solution.
Prosaic demands of use ARE usealy considered in a good security design. However, depending on the security demands of the information protected it may be low on the list. This is why security is a service function and not a drop in blackbox.
Inconvenience is a cost, and it must be addressed.
>The goal of security is not to build a system >that is theoretically securable, but to actually >make it secure!
Besides being somewhat inflammatory, in general what is theoretical today is often used tomorrow.
Examples:
Buffer overflows
Format string bugs
Dictonary password attacks
Man in the middle attacks
Re:Password Safe (Score:2, Interesting)
Since Password Safe allows long passphrases, I use the DiceWare method to choose the master passphrase.
http://world.std.com/~reinhold/diceware.html
BTW, the Source Forge developer says he hopes to port to Linux.
Re:Two minds about it (Score:3, Interesting)
I fear not. If the cracker knows that your password is a valid English sentence, then the search space is significantly reduced. For example, you can trivially discard any combination that doesn't include a verb. This observation alone probably takes the search space down to 6v*(45000^5), where v is the number of verbs in the dictionary, presumably much smaller than 45,000. A reasonable guess that one of the words is "password" would make the search space 6*(6v*(45000^4)). More importantly, most of your 45000 words are obscure. An attacker would likely initially try at most 5000 common words (which would cover every word in that password). All of a sudden, we're talking about 6*(6v*(5000^4)).
By making three assumptions, I have narrowed the search space down by maybe eight zeroes - a hundred million times easier - assuming 'v' is in the thousands range. Now, you might say I chose those three assumptions because I already know the password. That is of course true, but what you need to consider is whether the worst password in your entire system satisfies those assumptions (derived entirely from only the knowledge that the password is an English sentence). Crackers can get lucky, too.
In real life, you'd attack such a password by picking strings from the fortunes files, books, and other sources of quotes, and then we're only talking hundreds of thousands of tries. Remember that many crackers only need the weakest password.
Try this again, formatted. (Score:3, Interesting)
Passwords:
- Passwords and password rule circumvention
This is where we seem to be stuck. What about the following:
PaX:
- Total of 1-2% performance overhead
- Enforce non-executable pages to block security exploits in programs
- Enforce non-writable executable pages to block security exploits
- Address Space Layout Randomization to increase difficulty of actually activating security exploits
- Privilaged IO blocking to avoid altering the kernel
- Blocking of direct writes to ram and kernel memory to avoid altering the running kernel and getting around security systems or inserting malicious code
- Hiding of memory mappings to avoid information leaking which would negate the ASLR advantages
Grsecurity:
- Includes PaX
- Blocks many operations from happening inside a chroot() jail, thus increasing security by disallowing programs to try to gain access to devices, processes, and filesystem data that they aren't supposed to access
- Imposes an Access Control List system to extend control of file and device access
- Hinders OS fingerprinting with several network protections that randomize various ID numbers in various types of packets
- Allows user auditing and signal logging to detect attacks
How much crap did I list besides password issues? Quite a bit. There's more to consider than "Is root's password 'secure1'?" How about "Can I cause SSH to overflow before I log in, clearing root's password out so I can log in as root and take over the system?"
Password Stategy (Score:1, Interesting)
What a snoozer of an article (Score:3, Interesting)
OK. Has this been reported or observed anywhere else? I've never heard of it, or seen it myself, though I've only been using OSX for a little under a year. If anyone can point me to a reference, I'd appreciate it. The article doesn't give any refs. I don't understand how he's so sure it's an Apple bug, unless it's so well-known that, gosh, everyone knows it's an Apple bug without even needing a link to, like, a Knowledge Base article or anything... but if it were that well-known, I hope I would know about it. So I have my doubts about this. If anyone knows one way or the other, I'd like to hear about it.
But really that's not the main point of the article, right? It's just one security flaw in a fairly specific situation. So the article, as far as I can tell, is a few anecdotes and a bunch of "D'oh!"s. Oh yeah, plus some insults and derision for all the programmers and the university professors who taught them. Thanks a lot, Tog.
His thesis---that security needs to be designed to actually make things secure, not theoretically securable---is, well, it's OK I guess. For one thing, he doesn't really argue for it---just provides anecdotes. That's not a coherent logical argument. Worse, it barely even ties in with the anecdotes anyway. So the hospital requires TOO MANY passwords. That does **not** make it theoretically securable, OK? (I can require 200 passwords, but it's not theoretically securable if the computer and fax machine are in the hallway.) He's right that security systems have to aim for real security, but he's wrong in saying that the problem is that people aim for "theoretical securability". Am I wrong here? Is there ANY theory of anything under which these systems are considered theoretically securable?
The only common thread I can think of, apart from inadequate security in general, is that the people who designed the security had an incomplete approach to security; they secured one part of the system (e.g., getting in with a password) way too much, and other parts (e.g., physical security of the fax machine) not enough. Or, they were unnecessarily protective, at the cost of user convenience (as in the VW radio example).
If I'm criticizing the article, maybe I should try to be constructive about it, right? I guess the anecdotes really point towards the two different themes in the previous paragraph: security model should be "complete", and there should be some kind of a balance between security and usability.
I may be wrong about my interpretation of his article. If there's a better way to read this article as it's written, please tell me. I suspect not, but hey. Or just call me a monkey, that's cool too.
Well, to wrap it up, he has a good point, basically, but no argument for it. Just a few isolated anecdotes, not all of which I believe. This is not high-quality writing. Sorry, Tog. I've read of few of your user-interface-design columns, and I liked them a little better. This one just didn't do it for me, I guess.
zach
Not all security jobs are in trouble (Score:2, Interesting)
Re:Common Sense (Score:3, Interesting)
Okay, you might be thinking, that's not so bad. After all, you probably have a similar situation on your home machine. I know I do. But I'll bet your home machine doesn't have a password policy like this:
"Passwords must be at least 8 characters, with at least 2 alphabetic and 1 numeric/special character, must begin with an alphabetic character, must not contain special characters other than _, $, or #, must not be a word found in the English dictionary, and must differ in at least 2 character positions from the old password. Also, passwords must contain at least 5 different characters and cannot have a simple sequence of 4 or more characters (for example, 1234 or edcb)."
That is the actual copied-and-pasted password policy for the networked computers in our wing. After about 10 minutes of trying to come up with something memorable that the machine would accept, I finally gave up and it took me an additional 5 minutes to construct a string of random gibberish that the machine would accept. (I have it written down in a post-it in my notebook, of course.)
The traditional rationale for this nonsense is that the more complex a password is, the harder time an attacker will have brute-forcing it or guessing it. But wait a second... if these passwords are all verified by a server sitting across the network (such as a Windows logon), wouldn't brute-forcing the password be impossible remotely? I would think that any kind of login interface, whether local or remote, would have a simple algorithm that makes brute-forcing impossible such as by exponentially increasing the amount of response time for each invalid logon attempt. As for brute-forcing locally, well, you've got much bigger problems on your hands than a few compromised accounts if an attacker is able to run a cracker on your password database itself either on his machine or yours.
My first instinct, when I first read the password policy above, was to wonder whether such a restrictive policy would actually make it easier for an attacker to brute force because it shouldn't be all that difficult for an attacker to build a password cracker that simply skipped all of the enforced restrictions and only tried valid passwords. My question, for someone more educated in statistics or security than I, is this: would filtering for these password restrictions really result in a significantly smaller average search time before a match is found?
Compromise via a guessed password shouldn't even be very much of a consideration either. Guessing a password is more difficult than many would think. Your guesses would have to be fairly well educated and for that you would need to know the person pretty well. I think I've correctly guessed someone's password only once in my lifetime and that was because she was my wife and I already knew several of her other passwords.
So what it seems to boil down to is just what the parent comment states in bold. Increasing security complexity is causing users to simply ignore it, making the resulting system less secure rather than more.
As a side note, the Air Force is moving to public-key encryption with the private key being stored in a chip on our ID cards. This is a good start, but they have yet to implement it beyond the network logon. (I asked where I could ge
Re:Password management (Score:3, Interesting)
Technical techniques are detectable. They may be difficult to detect, but they are detectable. The "bad guys" seeing a password on a desk (or trash or whatever) is not detectable, and now you've now opened yourself up to the nastiest password leak of all. Even most stupid passwords are going to take more than 10 attempts to crack, unless it happens to be "password" which almost every cracker guesses first. If you have a worthwhile system to defend, you'll be aware of attempts to brute force your system, and you can take action.
Now, I know what your thinking: "What if they brute force against my password file/database?". Listen, if someone has access to your password file or database, you are screwed, whether you force your users to change their passwords or not.
Normal users create dumb passwords. What really needs to be done, in my opinion, is when you hire someone, they should go through a secure password training course. They should be given some techniques for creating a tough password that they can remember, and then informed that they should never, ever give out their password to anyone else, or write it down, or store it on a computer.
There is one final piece to the puzzle. You need to run a cracking program against your own password list once every few months. (Or more often for a system where security is paramount) Be sure that the cracking machine is not on a network! Move the file or database to the machine via sneakernet. Run the cracker on the list, and anyone it comes up with quickly should be told to come up with a new password. Frequent offenders should be required to attend the secure password training course again.
I think this would result in the most secure system possible. Sure, people are still going to write down passwords. They'll still have dumb passwords. They'll still give out their passwords to other people. But, you'll have limited how often that happens, and at least the majority of your users will have somewhat difficult passwords. Those people who have very difficult passwords can keep them, making for a secure system where users are more happy.
Re:Common Sense (Score:3, Interesting)
I actually had a discussion about this when the global security counsel of a larGE company (I won't name it here ;-) I formerly worked for announced the new password policy. The policy stated that passwords were to be a minimum of 7 characters containing at least 1 lowercase letter, 1 uppercase letter and 1 number or special character.
If you recall the days of the Lanman password hash, the hash was broken into two 8 byte fields. For passwords less than 8 characters, the second 8 bytes were always the same. Here is where the policy causes problems. According to the policy, the minimum length is 7 characters, so if we know the password is less than eight characters from the hash, we know it is exactly 7 characters.
So now consider the imaginary case that we have a hash for a password that's less than 8 characters. The password policy tells us that we won't need to attempt any passwords 1 to 6 characters in length. It also removes any seven character passwords that don't meet the criteria above.
Please forgive any math mistakes; these are only meant to be rough estimates. Using the character space of 26 lowercase, 26 uppercase and 42 numbers and special characters the entire password space is: 94^7 + 94^6 + 94^5 + 94^4 + 94^3 + 94^2 + 94^1 + 1 which is roughly 6.55 * 10^13. Removing the 1 to 6 character passwords reduces the space by a little more than 1 percent.
Once you remove combinations not allowed by the policy (all lowercase, all uppercase, all numbers and special characters, lowercase plus uppercase, lowercase plus numbers and special characters, uppercase plus numbers and special characters) you take away roughly 1.47 * 10^13 possibilities, leaving about 76.5 percent of the original password space. If the policy implements positional requirements (i.e. must start with a lowercase letter) the space will reduce even further.
On the other hand, the space is still pretty big. Keep in mind that l0phtcrack style dictionary attacks cover more than just standard OED words. If an intruder had access to the password hashes on an NT system of mine, I would be more worried about a modified dictionary attack (even with the policy you mentioned) than the password space that the intruder had to search.