Moving Beyond Passwords For Security

Naturalist writes with an excerpt from a New York Times story about the need for a more secure method for identification than the password-based system almost everyone currently uses. The article also discusses the weaknesses of the OpenID initiative to simplify the process. "The solution urged by the experts is to abandon passwords -- and to move to a fundamentally different model, one in which humans play little or no part in logging on. Instead, machines have a cryptographically encoded conversation to establish both parties' authenticity, using digital keys that we, as users, have no need to see. ...OpenID offers, at best, a little convenience, and ignores the security vulnerability inherent in the process of typing a password into someone else's Web site. Nevertheless, every few months another brand-name company announces that it has become the newest OpenID signatory."

Comments

Yes, we know.

[Anonymous Coward]

The solution is public key cryptography. The problem with that solution is that it only works as "something you have", not "something you know", which is the authentication mode of passwords. You can't leave "what you know" at home, but will you always have your smart card with you? Another problem is that secure public key cryptography requires a complete terminal under the control of the user, not just a card. The private key can never leave the user's control and the user must always know what it is used for. That requires a display and keyboard. Not something people want to have on them whenever they need to authenticate.

Re:Yes, we know.

[ratnerstar]

It can work as "something you know," all you have to do is memorize your private key. Kids these days; they want everything to be easy.

Re:Yes, we know.

[Kjella]

Yes, if you're always where there's phone coverage and you got battery. However, it doesn't solve the problem of a compromised terminal. That was what a bank virus did not that long ago, waited for the user to authenticate then sent money elsewhere "behind the scenes". Sure it might not get your email password but if it silently downloads your inbox compromising every password mail you ever got, well gee that's nice.

Re:Yes, we know.

[jd]

The US Government uses this method, except via smart cards. This started with the NMCI initiative. I was not keen on NMCI, as it used Citrix and centralized application serving. This creates a single point of failure (which quite often failed at the beginning) and a single, all-powerful account on a system (there's no other way of having a central system responsible for all privileges otherwise) on an operating system that probably isn't going to be in the Trusted class (ie: it ran Windows - and I am using the Trusted class in the Orange Book sense, not in any "popular" sense of whether people actually trust it).

PKI is a very sensible approach, but should not be used in isolation. This was discussed only a short time ago on Slashdot regarding "secure locks" - there should always be multiple layers of security, a reliance on a single layer is always going to be a disaster waiting to happen.

Passwords as a "bootstrapping" mechanism to enable the rest of the security sounds fine. It's something we already do with regards GnuPG/PGP keys, Kerberos, etc. They're weak, but bootstraps don't need to be that strong if you're using them in a multi-layer system. They're supposed to make it hard for anyone to tell if they've broken the other layers. That is sufficient.

There is, however, almost nothing else you can use. Biometrics are not safe (Slashdot has covered the breaking of many such systems) and not guaranteed to work (Slashdot has covered chimeras and other biological weirdness in the past). Two physical electronic keys won't give you significantly more security than one with twice the quality of encryption and just give you more you can lose. Call-back mechanisms are vulnerable to social engineering (if involving people) or replay attacks (if automated) since such methods have to use extremely primitive security as they are prior to authentication.

Re:Yes, we know.

[GuldKalle]

It's an ineffective way of using your phone as "something you have".
I propose installing a program + private key on your cellphone, and use that to encrypt a random token. Then you get a hash of the ciphertext on the cellphone display, which you enter in order to login.
It could even be nicely integrated into openID, bringing me to my next point:
The thing I just mentioned CAN be made by an openID provider (I was surprised that I couldn't find such a provider though), and it would make a lot more sense to make it for openID than for 50 different websites each with their own implementation.

Re:Yes, we know.

[JFitzsimmons]

And you can do that with openid. I got bored and made myself a GPG based openid provider. It isn't complete by any means since it lacks key revocation and such, but it is working and public.

http://id.l3ib.org/

Re:Yes, we know.

[GuldKalle]

It's not perfect, no. But it presents a significant extra barrier. And to overcome this barrier, the attacker must:

1. Get a program running on the phone
2. Wait for the user to enter the password (because the private key should always be encoded)
3. Get the private key out of the phone (although a phone by definition has communication abilities, most phones will alert the user if a program tries to use them).

And the strategy still has a key advantage over smart cards with displays, namely the logistics problem.

Re:Yes, we know.

[sam0737]

We should include the private-key encryption calculation in the 6th Grade Math class and require everyone to do it mentally in the exam.

"Beyond Passwords"

[apoc.famine]

I do not know that this is an accurate title.

Users on shared systems can easily set up a simple PIN code to protect any card from use by other users...

That almost sounds like a....password...

Really, this is an article about using things instead of passwords....which function like passwords....and using passwords when those wouldn't be secure enough. What a stupid fucking article.

Re:"Beyond Passwords"

[bjustice]

Did you read the next paragraph, or understand the rest of TFA?

The PIN doesn't return us to the Web password mess: it never leaves our machine and can't be seen by phishers.

Re:"Beyond Passwords"

[LO0G]

You're right. It IS a password. And it doesn't matter.

The PIN is a password that unlocks the smart card. In order to authenticate with the remote server, you need both the PIN and the smart card.

It's called two factor authentication. There are essentially 3 types of authenticators:
1) What you know (a password)
2) What you have (a key or a smart card)
3) What you are (fingerprint or retina scan).

Most web sites use one factor authentication - their security depends only on what you know (your password).

The primary attack that's involved here is an attacker attempting to guess/steal your password to a remote site. All they need to know is your password and they're in. And they can take your authentication information and use it from any machine on the internet - thus they can sell your identity and make money from that.

With a smartcard/pin combination they need both the PIN (what you know) and the smartcard (what you have). The PIN is totally useless to the attacker unless they also have the smartcard.

Adding the second factor to the authentication system does move "beyond passwords".

Convenience vs security vs stupidity ...

[blahplusplus]

Passwords can still play a role, the problem has always been user stupidity and convenience vs security. We always love to save time and anything that requires less effort = good for us, but at the expense of being less secure. Moving security to invisible layers is just asking for abuse by authorities, as if they didn't have enough power already via MAC address + ip binding in being able to track down and identify users by merely tooling around with the equipment right at the ISP end.

My bank uses multiple authentication using personal questions which I would only know the answer to and if you get the question wrong just once, it flags the account. The big problem is the amount of retries, you can't guess or brute force passwords on accounts that will lock after the first few failed attempts.

In my opinion it's probably best if we moved to gesturing, I find an interesting site here -
http://www.dontclick.it/

It could serve as an interesting basis for security, i.e. gesturing and opening the correct doors in a maze.

Re:Convenience vs security vs stupidity ...

[Saishu_Heiki]

Security versus convienience has been a large issue here at the hospital where I work in the IS department. Because all of the pharmacy orders are done in our clinical application, the state pharmacology board mandated that another layer of security be added beyond the physician's username/password. The result is a list of 60 person questions (hometown, number of brothers, country of birth, etc) that is drawn from randomly to ensure the person ordering the drugs is the one who is logged in and authorized. The problem was, doctors were answering "1" to all 60 questions so they would not have to remember the answers or be bothered actually reading the questions. If they had to use their ID badges instead, it would be an even bigger nightmare. They want speed and ease of use, but are reckless because data security is "my concern". Sometimes it is hard to stop the person with the gun to their head from killing themselves, regardless of whose responsibility it is.

Re:Convenience vs security vs stupidity ...

[Anonymous Coward]

The one thing that has always bothered me about retry lockouts is the denial-of-service opportunity. If someone knows your username, then they can harass you by expiring the retry limit. Even worse, they can let a bot do it. They won't brute-force your account, but they can ensure that logging in yourself is a huge headache.

Perhaps a modification to the retry lockout strategy would be to make it per-IP address. It would shift the danger to large botnets, which could still distribute the password attempts over many machines.

Of course, now this makes processing logins expensive, as each attempt requires consulting with a retry-blacklist. One might try making a single, global blacklist and then dealing with the support calls from people with infected machines who were blacklisted for testing other accounts without their knowledge.

Tough game to win, really...

Speaking of passwords

[Anonymous Coward]

I like that slashdot hides your password if you accidently type it into a comment.
Look: **********

Re:Speaking of passwords

[YttriumOxide]

Surely that can't work... if it hides your ******** whenever you type it, then it would make it really obvious what your ******** is if it's a standard dictionary word when you use it in a sentence. I don't think it masks ********s at all.

Re:Speaking of passwords

[my $anity 0]

12345

did it work?

Re:Speaking of passwords

[mortonda]

Sure, all I see are stars.

yes, it's a classic. http://www.bash.org/?244321

PEBKAC

[at10u8]

Problem exists between keyboard and chair, and the article does not address that aspect nor give any good workaround.

Re:PEBKAC

[houghi]

Indeed PEBCAK, because it is my fault that I have all these logins that I need to remember.
Let me see? I have about 12 different logins that I was not allowed to select myself. Of those there are 6 that I can not change the password. These are just the ones I use at work and do not include the once that are not personal, but are group login and passwords.
The other 6 I must change every month and to nt get mixed up, I use something easy to remember. And I have worked in worse places. One where I needed to change my password each week for certain access. So I started to write them down.

If that is PEBCAK, then so be it. It might just be my naive idea that if many people have an issue with e.g. a procedure, then it is not the people who need to change, but the procedure.

If you see that nobody can reach the peddles on his bycicle, don't ask for taller people, start making smaller bycicles.

OpenID

[Cyberax]

OpenID is _PERFECTLY_ compatible with passwordless authentication. For example, my OpenID provider uses Kerberos authentication.

I too feel that passwords are too weak. Something like special hardware tokens are much better, but there's no infrastructure for their distribution.

Re:OpenID

[Colin Smith]

Something like special hardware tokens are much better, but there's no infrastructure for their distribution.

They're also not cheap.
 

Re:OpenID

[CTachyon]

Also, many OpenID providers like MyOpenID let you generate a browser-side SSL certificate and forbid password logins entirely on your account. At that point, you can't be tricked into entering your password because you simply don't have a password.

Re:OpenID

[Cyberax]

For most applications "something held" (maybe with a simple PIN-protection) is perfectly fine. Like your keys, for example.

Good key revocation system is essential in this scenario, however.

Passwords are much overrated, anyway. Most users inevitably either choose weak passwords or just write them down somewhere.

Re:OpenID

[hackstraw]

Something like special hardware tokens are much better, but there's no infrastructure for their distribution.

USB thumbdrive, passphrase protected private key.

Once sshd can tell if a private key has a passphrase and its authorized keys can be centrally managed, then there is never a reason a user should ever type a password. Just unlock the private key locally, and you can go wherever you are already authorized to go.

I just think its so stupid that we have to type usernames and passwords all the time. The burden is backwards. Its up to the server to say yes/no, it already knows who is allowed on the system, and their capabilities (roles, authorization, whatever), all the user needs to do is say here is my ID, is it OK for me to come in?

I mean this is the way credit cards work. No password whatsoever, and I can present my card, and a purchase is made, no password ever.

Now, with password security, since they are insecure by design, then you have to change them, to ensure they are secure again, thus placing a burden on the user and sysadmins and help desk people.

I mean, I don't use a username/password to enter my $500,000 house, or to drive my $100,000 car, or to enter my workplace where there is many millions of dollars of equipment and data. Why do I have to enter a username/password just to go onto a computer that already knows I'm ok to be on the system?

Re:OpenID

[SanityInAnarchy]

However, "something held" can be considerably more secure than "something known".

Either way, the point is that TFA represents OpenID as a reduction in security, when, in fact, it allows you to implement whatever security measures you want.

This is a common misconception -- that OpenID is simply single-sign-on in new clothes. It's actually an opportunity to give the user responsibility for their own security, and that's a powerful thing.

This could just be my ignorance-

[FlyingSquidStudios]

But doesn't this restrict people to using secure sites only from their own machines? I have encountered situations where I was at friends' houses, relatives' houses or even a work computer where I want to do something somewhat security-sensitive like checking e-mail. Wouldn't this sort of security measure make that far more difficult?

totally safe authentication method!

[ocularDeathRay]

Jean-Luc Picard: Begin auto-destruct sequence, authorization Picard-four-seven-alpha-tango.

Beverly Crusher: Computer, Commander Beverly Crusher. Confirm auto-destruct sequence, authorization Crusher-two-two-beta-Charlie.

Worf: Computer, Lieutenant Commander Worf. Confirm auto-destruct sequence. Authorization Worf-three-seven-gamma-echo.

Computer: Command authorization accepted. Awaiting final code to begin auto-destruct sequence.

Re:totally safe authentication method!

[Saishu_Heiki]

I was always under the impression that this was a two-stage security system as well. There is the password ("Picard-four-seven-alpha-tango") and a voice-print analysis to confirm it was the correct person issuing the order.

Of course, I don't remember any time where Worf tried to use Riker's credentials, so I can't really back it up...

Re:totally safe authentication method!

[elFarto the 2nd]

IIRC, Data has used Picard's credentials, and he was impersonating his voice, so that would support your theory.

Regards
elFarto

Re:totally safe authentication method!

[Kidbro]

Sheridan: This is Captain John J. Sheridan. Serial number XO7Y39-Alpha. Security code: obsidian.
Ivanova: This is Commander Susan Ivanova. Serial number Z48M27-Epsilon. Security code: griffin.
Michael Garibaldi: This is Chief Warrant Officer Michael Garibaldi. Serial number V17L98. Security code: peekaboo.
. . .
Ivanova: Peekaboo?
Garibaldi: Would you have guessed it?

(linky)

How could it blame OpenID?

[sam0737]

OpenID does not required the use of password as the way for human to authentication oneself to the system.

It's just up to the OpenID signatory to use whatever technology to authenticate someone. This human interface is decoupled with the underlying authentication.

Although most public signatory currently use username+password, but it could be change. Say you could implement your own, using PKI to recognize your own certificate stored on removable media. If you gone crazy enough, nothing stop you from implementing One-time password + Biometric + whatever-you-can-think-of to authenticate yourself to your own signatory.

its not that hard

[circletimessquare]

i have trouble keeping track of all my usernames and passwords like everyone else

so i put it in passwords.txt in my shared emule folder, so i can access it anywhere in the world ;-)

smart, huh?

Kerberos did that years ago.

[khasim]

With Kerberos, your password never leaves your machine.

The machine you're trying to log on to sends you a random string that is encrypted with your password.

Your machine uses the password you typed in to decrypt that string. Which also contains instructions on how to continue the connection.

Your password never goes across the wire.

Re:Kerberos did that years ago.

[anachronous diehard]

Per http://en.wikipedia.org/wiki/Kerberos_(protocol), Kerberos is a symmetric key system which requires a trusted Key Distribution Center to also know the shared secret (a one-way hash of your password). The advantage is that a phisher (who doesn't have your secret) can't pry it out of you if . It does have the weaknesses common to symmetric encryption systems; KDC compromise, KDC unavailability, etc.

Public Key Infrastructure encrypts the transmissions with the public key of the destination entity instead of a shared symmetric key. Kerberos has extensions to work with PKI. In these, the KDC doesn't know your secret, but can recognize that you know it.

Operating Systems will have a secure storage intended to keep your private key from being slurped by a trojan. PKI hardware tokens improve on that by moving the private key into a separate device, with its own single-purpose operating system (which is easier to certify, as long as you stick with well-vetted algorithms instead of http://yro.slashdot.org/article.pl?sid=08/08/09/1812256). The private key never leaves the token; all operations requiring it are done inside the token. To crack this requires two separate cracks; physically obtaining the token, plus phishing, sniffing, or torturing the corresponding PIN from the token owner.

So you can pick how much security you want, and how much you want to pay for it. It helps to make both decisions at the same time.

Re:Kerberos did that years ago.

[huge]

The problem is websites that want 'pretty' login screens with text boxes for input, instead of using the builtin authentication methods available over HTTP.

Exactly, why to expose your own code to all the automatic probes that go around the internet when you could use "well-tested" webserver code instead? If there are problems with webserver authentication code somebody might patch it but if it's your own code nobody but you will be auditing it.

Sure, your authenticated users could still exploit your code once authenticated but that would at least limit the number of attempts.

It's not uncommon at all for this to be done on unencrypted pages (even some banks have made that mistake).

It's worth noting that HTTP Basic Authentication just base64 encodes the passwords but doesn't encrypt them. HTTP Digest Access hashes the passwords but is vulnerable to Man-in-the-middle attacks so you need to use HTTPS anyway.

What about digitags?

[nicc777]

My bank uses a combination of Digitag and SMS notification as added layers of security.

In South Africa, everyone with a bank account by law has to undergo a KYC process (know your client). This basically means that you as a client have to verify your ID at a branch (in person) with ID documents and some of your monthly bills. Your cellphone number is then captured to which all notifications of activity on your accounts are sent.

The Digitag is used during online authentication. As a further backup, a one time pin (OTP) is send to your cellphone. This OTP is required for certain transactions like once off payments.

Granted the system is not perfect (there is still human stupidity), but I would like to hear your comments on these tpye of systems, as they are becoming more and more part of our lives.

My reply, directly to the author:

[SanityInAnarchy]

I felt I had to respond to your article about passwords. It's been Slashdotted here:

http://it.slashdot.org/article.pl?sid=08/08/10/186203

But I felt it was important enough to write directly, and concisely, because you seem to have missed a fundamental point of OpenID.

OpenID promotes "Single Sign-On": with it, logging on to one OpenID Web site with one password will grant entrance during that session to all Web sites that accept OpenID credentials.

OpenID supports single-sign-on. There is nothing about it which requires you to use the same identity everywhere -- or even the same provider.

But more importantly:

OpenID offers, at best, a little convenience, and ignores the security vulnerability inherent in the process of typing a password into someone else's Web site.

Nothing about OpenID requires a password.

I'll say that again: NOTHING about OpenID requires a password.

What OpenID does is, in proper implementations, it allows us to sign in with any provider we choose. I could choose my own server as a provider -- thus, it's not necessarily "someone else's web site". And I don't have to use passwords -- I can use a password and a "security question", I can use public-key cryptography, or I can hire a secretary to sit at the server in question and only authorize requests when she receives a phone call from me.

Even if we assume everyone continues to use the same password, with the same account, everywhere, it's still better than a conventional login. With the conventional login, every site I log into could steal my password and use it to login as me elsewhere. With OpenID, only my OpenID provider can do that.

One single-point-of-failure is better than N single-point-of-failure.

You can't use Microsoft-issued OpenID at Yahoo, nor Yahoo's at Microsoft.

If true, that seems about on par for a technology in its infancy. Remember email? Used to be, you could only send mail to other people with the same ISP. Now, I can send mail to anyone, on any ISP, so long as I have their address.

So that says more about Yahoo and Microsoft's understanding of the technology than it says about the technology itself.

OpenID and Multi-Factor Authentication

[master_runner]

Although the password is still there, many OpenID providers are moving towards advanced multi-factor authentication. For example, when I (or anyone else) attempt to log in to my OpenID account, the account provider calls my cellular phone. I must answer the call and confirm (by pressing the # key) in order to log in. This means that in order for an intruder to gain access to my account, they must have my password and my mobile phone, and if anyone else tries to log in to my account the unexpected call will alert me to this fact. I also know that other OpenID providers support the hardware key popularized by PayPal that generates a one-time password for each login. Other OpenID providers (including mine) support authentication via SSL certificates. There's a whole range of alternative and multi-factor authentication schemes offered by today's OpenID providers, and over time more and more methods are being introduced. OpenID allows users to choose an authorization service based on the security that they offer rather than based on what website they want to log in to.

MyOpenID

[lattyware]

MyOpenID allows you to use a phone call to log in. When you try to login, they call, you, and you press hash, it logs you in. Free too.

Re:the real solution!

[Anonymous Coward]

We already tried that. It's called 4chan.
It did not work that well though...

Re:something you have?

[ratnerstar]

You can't prove you have the "something you have" as in reality anything can be copied and thus you might just have a copy. Most of the token "things" are really a case of "something (something you have) knows" which isn't much better than "something you know".

Right?

Right. Moreover, given a good hacksaw, biometrics can easily move from "something you are" to "something I have."

OpenID Isn't Tied to Passwords

[Daveman692]

There seems to be a slight misconception in the NY Times article around OpenID being tied to passwords. OpenID does not specify the authentication mechanism for the user to their OpenID Provider which means that we've seen many companies (including Microsoft) experiment with alternative authentication mechanisms atop OpenID. The big benefit OpenID then provides them is that they're instantly able to start letting users use their new authentication mechanism at any site which accepts OpenID logins. More about this over at http://openid.net/2008/08/10/challenges-facing-openid/.

Graphical Pattern Method

[BPPG]

At my university, they were trying an experimental password alternative that comp-sci students could opt-in for.

Basically, we were presented with an image; this particular image was a bunch of cars in a parking lot, with people walking or standing around. I think it was a 400 by 400 pixel image. To set your pattern, you had to click and memorize five or six arbitrary points in the image, and also memorize the order you click them in. The idea was that it was supposed to be a lot easier to remember than an equally powerful password. Some people liked the new system, while others had a lot of trouble remembering the exact position of each of their clicks. I fell into the latter group.

Re:something you have?

[amn108]

Still, punishment for murder is much greater than punishment for breaking into a computer system. Which means, the degree of effectiveness of a retina-scan biometrics is still formidable.

Now that I come to think of it, I also see that a password can be known by torturing the person who knows it, while the point of torturing a person for retina-scan or retina-sample is rather moot, I suppose. I am not sure what is more "pleasant" - to be dead or to be tortured.

Re:something you have?

[arminw]

....The complexity of cloning security tokens varies....

Who needs to clone or copy anything? Nobody has ever car-jacked a vehicle by sticking a gun in the owner's ribs and demanding the ORIGINAL key? Nobody has ever robbed a "secure" vault by kidnapping the person who has legitimate access to that vault, key, combination or both?

Anyone who can come up with a security system that uses NEITHER what you have nor what you know would win a Nobel Prize and become extremely rich.

I have you beat

[Iamthecheese]

I got a tatoo of my private key on the back of my hand!

Re:beyond one password to another

[LO0G]

But it's not smoke and mirrors, IF you're looking at the realm of threats to your data/transactions on the internet.

What makes your password so valuable today is that the password alone is sufficient to unlock access to all your online data.

A two factor auth mechanism renders the password effectively useless, especially if the smart card implementation is competent. At a minimum, it raises the bar for the attacker dramatically higher than it is today.

It's not possible to have perfect security. All you can do is to make it harder for an attacker.

If I had a choice between using strong passwords (with the knowledge that strong passwords either (a) get re-used often or (b) get written down) or using 2 factor auth, I'd take 2 factor auth in a heartbeat. It's dramatically better than simple passwords.

Please note that there are other schemes that use a PIN that are NOT 2 factor auth that ARE smoke and mirrors. For instance if you use a keylocker application that requires a pin to access the actual keys, the security provided by the keylocker IS smoke and mirrors, the if bad guy can steal your password they can then use it to retrieve your passwords and it's game over.

But proper 2 factor auth relies on the CPU on the smart card (that's why it's called a smart card) for every auth sequence. If you don't have both the card AND the pin, it's worthless.

I actually use a smartcard every day

[pointbeing]

I work for an agency under DoD and have had what they call a Common Access Card (CAC) for more than three years.

Leaving my CAC at home has never happened to me but I imagine the experience would be fairly uncomfortable as the CAC is also used for building access - someone would have to sign me into the facility if I forgot my smartcard. I don't imagine I'd have to be embarrassed that way more than eight or ten times for it to sink in that I need to keep my smartcard with me ;-)

Humans (at least most adult humans) are conditioned to carry their driver's license with them when they operate a vehicle so learning to carry a smartcard with you wouldn't be all that difficult. To address the issue of requiring a keyboard and display (and a smartcard reader) there are contactless smartcards available and I *think* the technology's compact enough to include in a cell phone or other device.

IM frequently less than HO physical security will always be paramount - a physical token requires a user to have both the token and the PIN to that token to access a protected resource. In this agency there have been a few misplaced smartcards but there hasn't been one instance of a protected resource compromised because a bad guy had both the user's CAC and the PIN to it.

People tend to write down "what they know" if it's fairly complex - which compromises physical security. All I have to remember is an eight character PIN. My PC will lock my CAC after three unsuccessful PIN entries, which requires me to visit the card issuer to have my PIN reset.

All in all it's been fairly secure and easy to use. The transition to smartcards hasn't been completely painless but these days I use the card for building access (I have access to the raised floor area in the basement), to the network (smartcard authentication to the network is mandatory), to secure websites hosted on the network that use CAC authentication and to government-only applications that ping your smartcard to see if you're supposed to be running that application.

All in all it's been a pretty good thing and I was originally one of the naysayers on the project.