Slashdot Mirror
Real Security?
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?"
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.")
Voice recognition can by bypassed by a $10 piece of technology known as a "tape recorder".
And it can fail to recognize a valid user if they happen to have a sore throat.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
About a decade ago, I was a software deveopler working in a building with 2000 users. Back then we wrote apps for win 3.1. Most users 10 years ago were even more clueless that users today, so we often had to install software for them. We would show up and tell them that we need to install something, they would then usually say fine and go take a coffee break. Being win 3.1 we almost always had to reboot for one reason or another in the install. This would then leave us needing to log back on the users computer with the user not there. At this company passwords had to be changed every 30 days and include both letter and numbers. Nobody could remember there password, so when we needed to login and the user was not there, we would just open there top desk drawer. 9 times out of 10 the password was written on a sheet of paper in the drawer. It was amazing how many people did this.
Thanks for providing a classic example of a bad security idea. Your voice is not unique to you. Anyone can record it and play it back.
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.
I recently read a document proposing an alternative approach to an aspect of password management. I have since adopted this approach.
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.
> thisismylongasspassword
/usr/share/dict/words has over 45000 words
p roacheZ
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.
Cut that out, or I will ship you to Norilsk in a box.
that's why I am still fighting with corperate for a great security system here at work.
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.
Do not look at laser with remaining good eye.
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.
It shouldn't be amazing. Average people don't give a shit about security, nor should they. It shouldn't be a part of their jobs, or at least it shouldn't be something that interferes with them.
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.
Hey freaks: now you're ju