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?"
mirror (Score:2, Informative)
D'oh!
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.
That sounds a bit contradictory, but I will soon prove my point. Before getting into the proof, however, I would like explain that it is not solely the security people's fault. They have all attended one D'ohLT University or another, where their professors have carefully groomed them for their current state of profound D'ohLTism. That's the problem with being D'ohLTed; you are very likely to turn around and D'ohLT someone else.
My wife, the Doctor, was working over the summer at a local hospital. They are fiercely into security, requiring no fewer than four sets of passwords to navigate their system. And why not? There are confidential patient records on those systems! By golly, they ought to have eight sets of passwords, and really make things secure!
So works the mind of a D'ohLTish security engineer, working feverishly away in his cubicle in the basement next to the steam plant.
Take him out for a walk. Let him see the sunshine for the first time in years. Introduce him to some normal human beings. Be gentle at first; these are creatures with whom he has had no contact since being sucked into the depths of the university system.
Then, when his pallor begins to fade and he begins to take on signs of socialization, take him into the offices in the hospital and let him see the four sets of user names and password clinging to the monitors on yellow stickies (e. g., Post-It Notes) or, for the more security-minded, slid into the top drawer where no one would think to look.
D'oh!
Only a D'ohLT would come up with a security scheme that is so overly complex that it's guaranteed people will write down their passwords. And yet, this kind of D'ohLTishness is par for the course with these guys. They are the most clueless profession I know, and they are showing no signs of getting any better.
Of course, there's always room for more retardation of productivity, and, if it can be found, these guys will do it. After the first six weeks, my wife had received only two of the four sets of usernames/passwords, and she'd had to speak to no fewer than seven people to get them. Two weeks of further extreme effort finally produced the last two sets.
What was she doing in the meantime? Instead of spending full-time repairing people, which is nominally her job, she wasted hours camping out in another doc's offices, using his computer (and passwords--they were right there on the sticky note) to do her work.
Meanwhile, the other doc, bumped from his office, would go and gets an extra cup of coffee. The security D'ohLTs had thus not only opened up your medical records to anyone schooled in the use of sticky notes, they were pouring money down the drain in the form of lost productivity and company-supplied coffee.
D'oh!
Fortunately, of course, this problem is self-limiting. Yes, she only worked at full throttle for the final two weeks of her ten-week stint, but when she returns in December to work for another three weeks, her user names and passwords will all be waiting for her.
Except unused user names and passwords expire after 90 days.
D'oh!
Even constant users have to make up (and post on their computer monitors) new passwords every 90 days, even if they keep their user names. Expiring stuff is the only way these guys can prevent the unthinkable: memorization. Once people memorize the little devils, they don't need their cheatsheets anymore, and then, suddenly, there's real security. They can't let that happen!
Hospitals all over the country now are
Re:thanks for telling everyone my password, asshol (Score:2, Informative)
Re:Two minds about it (Score:3, Informative)
Those that are, probably also type the password too many times a day to make this practical.
The fact of the matter is that guessed passwords make up far less than a tenth of a percent of all intrusions.
By the way, all reasonable systems support long passwords. There's really no excuse. I don't know what "if systems supported it" is supposed to mean. I can't think of a modern system that doesn't support long passwords.
Re:I would If I could ;] (Score:3, Informative)
To bad many sites are disallowing special characters for fear of sql injection attacks.
This is a shame, since it is a *very* easy fix (store MD5 hashes, not plaintext, or escape the string before storing it) and it only inconveniences users. Oh well. A simple text file on my hard drive fixes that problem :-)
Re:Definitely (Score:5, Informative)
A pretty easy way to generate passwords that pass most picky password approval checkers is to take a phrase that you can easily remember, and then take the first letter of each word. Include punctiation to get the requisite non-alphanumeric characters. Make at least one numeric substitution if you're required to have a number. For instance:
N4N.Stm.
("News for Nerds. Stuff that matters.")
Re:Two minds about it (Score:5, Informative)
And it can fail to recognize a valid user if they happen to have a sore throat.
Security is a process (Score:4, Informative)
Every day I get reports from logwatch and tripwire on all the systems I look after. I look them over and query anything that catches my eye as unusual, or that doesn't correlate with the system-updates downloaded overnight. It takes about 10 minutes, and I do it over the first coffee in the office. It's just part of the routine. I insist on good passwords, and the machines are firewalled as much as possible. Got to leave that damn port 80 open though
I don't have the most-secure servers in the world, but I'll notice pretty quickly if there's something wrong with one of them, and I get an SMS if the chkrootkit program discovers anything...
I have a client who had an annual security-review process, and was hacked into, about 3 months after the review. The attraction was the bandwidth they have, I guess, and the first thing they knew about it was when that 200mbit pipe went crazy spamming people left right and centre... Their attitude changed when they suddenly got charged a lot of money for doing something they didn't even know about!
Simon.
Re:Forced password changes (Score:5, Informative)
Re:Two minds about it (Score:5, Informative)
Also, biometrics are worthless as the sole factor because if copied they can not be changed.
If you care this much about security, use s/key (or OPIE) or any similar algorithm. Let the user carry around a device that calculates the next password. RSA securid is nice if you don't trust your users not to share their passwords, though not as secure as s/key.
All the hard problems are solved. Everything that's left is human factors.
Re:Passwords? OT (Score:3, Informative)
Interesting... that has to be one of the longest lived funny mod triggers.
Current funny triggers: SCO jokes, Golum speak.
Declining funny triggers: I, for one, welcome our new
Recently deceased funny triggers: Yoda speak
Deceased, but still occasionally funny: All your base..., In Soviet Russia...
Sure, your bank account first (Score:3, Informative)
Password management (Score:4, Informative)
The paper said that one of the biggest threats to password security was the frequency that changes were required.
It seems that a fairly accepted norm is coming in to being in the form of organisations requiring their users to role their passwords once per month, and requiring that these passwords are unique. The problem with this requirement is that people are asked to remember so many passwords that they are tempted to either use weak passwords, or to write them down and stick them to something. Hence the previously secure password is now compromised.
The document/approach I read/have adopted is to stop requiring users role their passwords every month. I now request users to role their passwords every 3 months (once per quarter). As a result in any year they have to get to know only 4 passwords (instead of 12), and as such can handle better quality passwords more easily.
My users are far more happy with this approach, and now see it as a reasonable compromise. As such they now buy-in to the concept and we find far fewer people breaching the password policy.
Simple way to remember passwords (Score:3, Informative)
Re:Two minds about it (Score:5, Informative)
That's better than you think. My
in it, which is probably typical. The above password is six words long (which
if anything is pretty short, as sentences go). That means you can brute force
it in about (45000^6)/2 tries, on average. Compare that to a typical "strong"
eight-character password (e.g., "bVi-Q*cY"), which can be brute forced in
(N^8)/2 tries, on average, where N is about 100 or 200 or so, depending on
your character set. The sentence starts looking pretty good -- and it's a
*lot* easier to remember.
> thi!$1smyp4$s
Yes, increasing the length to over 12 characters greatly improves the security
of a traditional ugly password. (N^13)/2 is about N^5 times better than
(N^8)/2, so with an N of around 80 characters (upper and lower case letters,
digits, and about 20 common printable punctuation marks) that's about a
three-billion-fold improvement in the time needed to brute-force it.
I personally tend to favour a combination of these approaches. Take your
sentence (say, "I tend to favour a combination of these approaches.", make
a handful of key substitutions, and you get a password like this:
I-t3nd-2-PHavour-a-c0mbinat|on-0f-these-ap
The sentence is easy to remember. In addition to the sentence, you have in
the above example seven substitutions. That's a total of eight things to
remember, barely (if at all) harder than tB8k^yQp and pretty much impossible
to brute force. (If you do the arithmetic on this sucker, it's impressive.
Even assuming a clever modified dictionary attack, the sentence is nine
words long (nine *words*, not nine chars), and furthermore there are
several possible ways to mangle each word. The mere electricity your CPUs
would use up running the possibilities boggles the mind; whatever the
password is protecting, you could buy it cheaper.) Then you have to worry
about things like sniffers, surveillance, and rubber hose cryptanalysis, if
the password unlocks something worth anyone's trouble to bother with all that.
MacOS X : Use the keychain (Score:4, Informative)
The upshot of all this is that it allows you to generate good, strong passwords like series of letters, numbers, and special characters that have a high amount of entropy but are too difficult to remember. So long as you have a very strong login password (this was not possible in MacOS X 10.2.x and earlier), they will be protected by the keychain.
This is similar to Bruce Schneier's Password Safe [schneier.com] and is more convenient in many respects than his solution of keeping his passwords written down on a piece of paper in his wallet. He argues that we all have a lot of real-world experience at keeping our wallets safe, but I have a lot of passwords. How many do you have? Does anyone else dig around in your wallet, like your wife? What if she found out you had a password to someplace you shouldn't, like... uh... Slashdot?
I like my keychain. I'm surprised Tog never mentioned it. Wasn't he an Apple guru at some time?
Re:Two minds about it (Score:5, Informative)
I have a test system that cannot be cracked form the outside. all users' "paswords" are 4 digits in length. They use a iButton to log in, simply insert it in the reciever on the monitor (it's on a keyfob on ther keys.) and type your pin number.
without the iButton you cant get in or access data, without the pin the ibutton is useless, and dont try to crack the code, you have 4 tries and then your ibutton is erased. you have to get it re-encoded before it will work again.
no more taped passwords under keyboards in drawers, on monitors. the users love it. and it integrates with windows NT and 2000 just fine. (ibutton.com if you want to find a link to the software/company that sells what I am using.)
I can make ibuttons that are single use, and we can have those same ibuttons work as the door entry card-key.
if you want more security, you can get java ibuttons and have a program in the ibutton play cryptography with the computer and generate a random access key on every access, or whatever your heart desires...
you want high security? you have to use a security device to reduce the human factor... ibuttons are the cheapest solution.
Re:Two minds about it (Score:1, Informative)
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 am forced to change my password every month at work. So I change it, and then change it again back to my nice 3 character password. Why should I type 8-12 characters every time I login?
Speaking as a former cracker, frankly I don't think its even worth the hassle. For the very important stuff, yes, you want a good password. But for the login on my PC, if someone gets into our LAN somehow, my PC is already fucked, they don't need my login to do what they want to do. And its not like they will try a dictionary attack on my account. I would imagine they would go after the admin account first, but if they're already on the LAN, everythings pretty much fucked as I already mentioned.
security is about economics (Score:5, Informative)
Security is nothing special in itself, it's just another aspect of a problem: all problems have many aspects and as you suggest, usability is another aspect of a problem. Turn the technical aspects of the security lever the wrong way (e.g. too frequent password changes), and you lose on usability, and this potentially has a negative impact on the social aspects of the security level (e.g. the passwords are written on a post it note).
Really, it is about economics and engineering: using the measured amount of resources to solve the problem holistically: technically and socially - understand where all the impacts and flexibile point are. This is no easy task though. Peter Neumann and RISKS have been teaching us these lessons for many years - so there's nothing new here, but it is important to continually reevaluate.
Re:Forced password changes (Score:5, Informative)
Does this suck? Sure seems to make your job as an admin harder. But the fact is, you can't rely on end users for security anyway. What happens when Joe in accounting finds out he's about to get downsized and takes it out on the network?
If you secured it right, nothing. He deletes some information, and you get it back in a matter of minutes from the awesome backups and transaction logs you maintain. You invalidate his login, and it's like he never existed. That's security: having a way to fix things when they go wrong, not assuming nothing will go wrong because you demand so much.
Security against hackers is no different. Make sure they can't sniff passwords, make sure nobody has too many rights when they come in to the system from the outside world. And when you have to allow them access to something, make sure they never can do more than a day's worth of damage.
We have a lot of customers who are complete idiots. We know there is no way they will maintain useful logins to our system -- most of them use one login (same password as the log in name) on all of the installed computers they have, because it's easier. So, our new products were designed around this. Nothing is ever deleted from the system using the client application. The client's login can only read information on a server, or mark it invisible. The "root" logins are only known by a handful of people, and are only accepted from the console. And just in case, the whole shebang is backed up daily to tape, and the transaction log cloned and packed hourly.
So we can have our customers call and tell us "My login is carl, password carl" and I no longer roll my eyes. Because "carl" doesn't do anything more than peering through the window of an armored car.
Missing the point of the article (Score:2, Informative)
All the responses about how/why to select passwords miss the point that if the user doesn't have an incentive to remember them without the use of sticky notes, the password complexity is useless. Same if the rest of the system allows the passwords to be sniffed on the network, sent in clear somehow (by return e-mail for example) or any other weak link in the chain.
The example in the article of the hospital (and note that all in the US are under the same gun) points up the fact to me that either the IT person didn't understand the problem or was trying to cover their butt because they lacked the authority to put in place the policies that would make the users actually follow the policies and I'm betting that it was the latter!
If I'm in charge of security (not just the IT portion of it) and management won't let me put in place a policy that spells out what will happen to employees that subvert the security implementation and back me up when I have to apply the policy's warning and penalty portions, then I'm out of there!
1 - Anyone caught writing their password down on anything will suffer punishment
2 - Anyone allowing anybody else to use their account/password will suffer punishment
3 - Anyone leaving their workstation logged in and not protected with the approved screensave/password will suffer punishment
etc.
Punishment to be:
first offence - note in personnel file and severe dressing down including things to the effect that if they can't remember the passwords then they obviously don't have the necessary skills for the job
second offence - time off without pay or outright firing
if allowed to get to a third offence, it is either them or me - and I'm betting it is them, and damn the unions and labour relations - they're unfit for the job.
And the response to the post about it being a matter of managing the liability - if the employee is still an employee and the above policies are not in place and followed through on, then the liability is on the company/HMO or whatever. The penalties are enough to bankrupt an HMO and nobody will take "it was the employee's fault" as an excuse no matter how onerous the security techniques look on the surface. It is the follow through that proves that the policies are what they need to be - enforced.
I'm just glad that (so far - but Jan 1 is coming) Canada doesn't have the laws that the US has currently.
Safety engineers have known this for decades (Score:3, Informative)
That's insightful, too bad you're only +4 as I write this.
"User error" is a phrase that makes safety engineers cringe. The more detailed an accident investigation, the less likely it is to blame the equipment operator. What usually turns up is that the system doesn't supply the right information (Three Mile Island didn't have an instrument to dislay coolant level in the core) or the system has trained its users to do the wrong thing (like, oh, double-clicking email attachments).
Believe me, there are security people who understand that an overly awkward security measure is worse than useless.
Re:Don't know my own password (Score:2, Informative)
That's pretty pointless, since only the first 8 characters of your password are significant in Solaris unless you've replaced your authentication mechanism....
Re:I do the same, with no expiration... (Score:3, Informative)
Okay, I'll byte:
It's an aphorism, but it's still true: "security" isn't a product (like a password), it's a process. Just because you have strong passwords, and decent newtork security (firewalls, NAT, etc.), never assume that you're invulnerable or too small to attack. I don't mean to sound snarky, but I think that you should always assume that passwords will be comprimised somehow, given enough time.