Slashdot Mirror
Password Security Panned
museumpeace writes "Considering we just discussed passwords yesterday, is an uncanny coincidence that Technology Review runs an article today in which
Michael Schrage quotes a couple of security experts as being of the opinion that passwords are useless, with many negatives [the tougher rules only make them harder for users to remember, not harder for hackers to guess] But Shrage's suggestion that passwords are a weak bandage where system security admins and developers need to institute deeper security mechanisms such as "suspicion engines" has problems too. Any hidden filter meant to compare traffic on your account against profile of "normal" usage strikes me as both an invasion of privacy and a sure fire way to multiply calls to the help desks when a false alarm tosses out a legitimate user."
Why permit reusable passwords when you can use hardware tokens or free one-time password systems such as OPIE (formerly Bellcore's S/Key project).
Most free Unix systems ship with SHA-1 capable S/Key support included.
From TFA:
Somehow, the world's ATM banking systems have managed to get by with a bare minimum of fraud for more than 20 years by relying upon only four-digit codes. So what do the banking geeks grasp about password management?
While the article continues to say that simple passwords are good, it overlooks the other half of the equation: the ATM card. Without both, no access is granted which seems to be the strength of the ATM.
The prevelence of password only authentication seems to be a hardware problem. Everyone has a keyboard, but almost no one has ( for instance ) a securid token.
A USB dongle might be the easiest solution, although standardization is obviously a problem. Gawd knows I wouldn't want to have one USB dongle for yahoo, one for NYTimes, one for my bank, et. al.
A Human Right
Use Bruce Schneier's Password Safe if you cannot remember passwords, but saying that passwords are useless when they are hard to guess because they are hard to remember, so we should use no passwords at all so there won't be anything to guess in the first place is the most stupid thing I have ever heard. If not using secrets that people can remember than what? Biometrics? Oh please... From the article: "79 percent of people questioned on the streets of London revealed such desirable security-sensitive data as mother's maiden name and birth date." Really? People revealed such secrets as their birth date? Let us all stop using passwords then! This is just laughable.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
The time you want to limit the character set used in a password is when the password goes into a web form.
Allow in ' and some others, and you're inviting SQL injection attacks. Allow in left angle bracket and some others, and you're inviting cross-site scripting.
No sane person would worry about cross-site scripting in a password entry field, but nonetheless web developers have the reflex of limiting incoming characters to a supposedly safe set.
it better be stronger than the 40 bit key used for current car keys...we just had a /. art on how kids at JHU built special cracking hardware that could recover the cryptokey for any of the millions of RFID tagged car keys. If you drop you keys and the bad guy picks 'em up, you are wide open even if he only has them for about 2 hours and then hands them back to you.
SLASHDOT: news for people who can't concentrate on work or have no life at all and got tired of yelling back at the TV.
I don't work in security of any sort, and I agree with you that more characters means better security. My immediate guess is that although it may make the password more crackable from one perspective, having fewer characters to worry about would make it safer to run the password through many API's.
Many string-related functions will do unexpected things with some special characters, and unless you know everything that it might do with every character, and all the ways that people might abuse this, it can be risky to assume that they've all been caught. In an ideal world, the programmer would know them all and know exactly what's happening to the password when it's processed, but I still know lots of great programmers who wouldn't be aware of several gotcha's in the printf() family of functions, for instance, that might be abused by crackers in one way or another.
Especially if some software was being coded in a group and everyone had to understand it, I'd sympathise with coders or managers who'd prefer to go with a password system they understood rather than gamble they knew more about their libraries than potential crackers.
Them limiting the characters indeed is a bad thing (making cracking passwords somewhat easier). But I'm a lot more worried about the reasons why it does so. Do they just use it as-is, plaintext inside a SQL query ala SELECT * from Passwords WHERE login="your_login" AND pwd="your_password"? That's a very scary thing. SQL injection galore, and that also means passwords stored in plaintext along your username and personnal info. Someone could get access to all the data. I use salted SHA1 hashes of the passwords (at least) on all my login pages, and even then that's pretty minimal. And if they use plaintext like that, the chances of them using SSL (or being security minded in any way at all) is pretty low. And with people sharing passwords between many sites (as you can only remember so many easily) it wouldn't be nice if someone got a hold of your "common" passwords.
///<sig
Realy, security isn't THAT hard.
Now i'm just a humble php web application programer, but sheesh while 1 or less character is indeed a huge diffrence it isn't going to matter shit.
On the other side, only alowing nummbers and lower/uppercase chars is simply dumb.
The thing i most often do, is simply letting people use UTF-8 for password.
It's like half a hour of work or so to make sure your entire site/programming/DB supports UTF-8 and if that's done, you just bumped up your list of possible chars a magnitude.
(and offcourse, being able to have a password in turkish is quite funny.)
secondly, the posting of your password isn't the problem. There are many javascripts out there to pre-encrypt the password via a dynamic hash, that could be depending on a nummber of variables. (date/ip/heck why not moon phases while where at it)
Then when the password arives at the server you simply decrypt it, and re-encrpyt it to md5 or sha or whatever.
also, SSL is funny, but not meant as a sure fire way to protect your connection. It's simply another layer of security, not a sure way of securing your web application.
The best security protection comes by design.
I've made a remote service for a rather large website a few months ago, that i secured by simply not sending any critical information.
It was for a remote image conversion server, so that the stock images site wouldn't have such a strain.
Now becouse of the design the worst thing that can happen is a man in the middle attack where the conversion server get's DOS'ed with requests to convert images.
which is a accapteble risk, and quite a small one becouse of rotating verification checks. (actualy based on the phases on the moon. (hey your a geek or you aint) and a few other variables.
And SQL injection, please if any serious programmer working on a project where security is a "real" issue. Then making sure that your security commponents are secured against SQL injection and the likes is simply going to be a standard point on the task list.
accompanied by some unit testing that will try just that.
"The time you want to limit the character set used in a password is when the password goes into a web form."
;)
My favorite is when the password contains an '@' sign and they use it to log onto a site in internet explorer. Hilarity ensues.
In the free world the media isn't government run; the government is media run.