Ask HN: Why are we still using passwords?

15 points by arohner ↗ HN
IANASecurity Expert, but there are several on HN. Hopefully this will start an interesting discussion.

1) Why are we still using passwords to authenticate people online? And by "we", I mean most big public websites. Google, Facebook, Twitter, Gawker. It seems like some sort of key-based, public/private algorithm would be better than the current mess. Is this correct or am I forgetting something?

2) What would the optimal solution look like, assuming the browsers supported everything necessary?

24 comments

[ 3425 ms ] story [ 3086 ms ] thread
The password is the simplest and most straightforward method of authenticating a user. Yes, you could go with a physical key (Near Field, USB, card, etc), thumbprint, eye-scan, or voice but all of those have their failings as well. How many stations have thumbprint scanners? My laptop does but I'm the only one I know and it is more a PITA. How many have cameras for facial recognition or eye scanning? Not mine. How would you access the site when you don't have your physical key on you? Couldn't your voice be just as easily hacked?

There is no better security for common use than the password... and it is just as effective as anything else with the added benefit of being universally applied if it is a decent one.

I know this isn't exactly your point... but I think we're finally seeing passwords go away... and using facebook, etc. as universal logins.
gah! You made my head a'splode with the involuntary reaction I have any time anyone mentions universal login.

I really dislike the idea of being forced to use any one service in order to access multiple different services. I actually will go to rather extreme lengths to avoid this.

I personally dont like universal logins not because I'm averse to them but because of how difficult they are to use at the moment. Everytime I tried to use open ID its the worst experience in the world.

Also, I hate fb so I deactivated my account. So that clearly means that I wont be using fb for anything. So, universal logins need a lot of work.

The OpenID concept is completely foreign and inaccessible to me, let alone my mother. Log in by giving it a URL? What?
I'm not a security expert at all, but what's the point of a public key supposed to be if all you want to do is authenticate yourself?

Why would you want to use (e.g.) an RSA key for authentication, forcing you to carry around a data fob or something from computer to computer, instead of using a password or passphrase that you can actually remember? Ordinary users would flip out if you asked them to do that. If you really want a super strong key, you can simply use passphrases that don't suck, or you can always use a password manager like KeePass that encrypts your weak passphrases with a strong master key.

The point of RSA authentication is you can give everyone your public key, and they can authenticate you without knowing your secret. Then, in case of something similar to the Gawker breach, the attacker has only the username and public key of the user, but not the private key, so they can't use it to get into any other site.

Strong passphrases is also not enough, unless the passwords are unique across sites. Some HN users may use unique passwords, but normals don't. I don't do it with 100% regularity.

What you're suggesting is that a user give a site their public key, receive some site-supplied data encrypted with their key, and be forced to decrypt it to log into the site? I guess that sounds fine, but it's no more or less secure than using a unique password, and again, now you need to carry your private key around everywhere that you want to log into anything, unless you plan on memorizing that sucker.

I suspect the real result of such a scheme is that everyone's private keys to everything would be sitting around unencrypted on USB drives and written on pieces of paper, so it would be even easier to steal their identities.

I think the solution is still -- use a password manager, and then it's easy to keep track of unique passwords across sites.

> If you only give someone a public key, > how can they authenticate you based > on that? You must be giving them some > piece of private data, or else anyone > could authenticate as you.

That's not quite the way it works. There is no shared secret required. With my public key you can create an authentication challenge that allows you to validate my identity without ever seeing my private key (or, for that matter, you can send me a message that only I can read).

Yeah, I figured out what he was getting at a moment after posting, so I edited my post with my core objection, which is just that there's really no benefit I can see to doing that instead of using memorizable passwords.
1) Why are we still using passwords to authenticate people online? And by "we", I mean most big public websites. Google, Facebook, Twitter, Gawker. It seems like some sort of key-based, public/private algorithm would be better than the current mess. Is this correct or am I forgetting something?

Public key crypto still requires a private key - which is basically a password that is too long and obscure to be remembered by a human. And therefore has to be stored in a text file on your computer (a security risk in itself; I'd presume most people don't currently do this with their passwords). And good luck logging in to Facebook from a friend's computer.

There is a major difference - a password is known by the host. Of course they salt and hash and use bcrypt to secure their storage of it, but ultimately, a password is a shared secret between you and the site.

A private key is fundamentally different - it is private. You never send it to anyone, ever. So it's safe to use just one, because nobody else will ever see it.

As you alluded to, the problem then becomes managing that key securely, and also generating & distributing keys for non-technically inclined users.

OK, but bcrypt works! As far as anyone knows, the best you can do is just brute-force it, which is the same situation we're in with public key cryptography. The only substantiative difference is that passwords are often of a length and complexity that actually permits brute force or a dictionary attack -- meaning we're back to, is it small and memorizable, or a big binary blob, as being the distinguishing property.
You're assuming that the web sites use bcrypt. From the perspective of a web user, public/private keys allow me to not trust the web sites.
That's true, you don't share a private key with an authenticator, so it's unlike a password in that sense - but it's still what-you-know authentication, and any what-you-know authentication that a user can't actually know/remember is impractical.
Given the current infrastructure, yes, it's impractical.

But a correct infrastructure could be easier to use and an order of magnitude more secure.

And it wouldn't have to be rolled out all at once. I really wish my bank gave me the option of signing in with a private key today.

A private key (or client cert) is generally more of a "something you have" than a "something you know" credential.

(unless you memorized your key - it's something you have, not something you know)

Well, it's data. I guess it does reduce to "what you have" given that it's not memorable, but as we all know, "what you have" is less convenient than "what you know".
What if your iphone/android device helped you manage your private key?

A website could send a push-notification to your phone. You as a user would then have to say "Yes Its me logging in" and voila your in.

One way would be the same thing you do with "forgot my password" links. You enter your email address, a link with a random activation key gets mailed to you, click on the link in your email client and get logged back in. The activation key would have a limited valid span, say 30 mins, so even if anyone got hold of it it would be useless.

The disadvantages are a) your email can be hacked and b) it's a bit inconvenient for the user. Also you'd need SSL to protect the key, which would be in the URL.

This is my de-facto password management scheme right now. I call it "log in via email" (as opposed to log in via facebook or google).
There is stuff like RSA secure id. they ask for a password, but then also for authentication number... where you have a device that shows you the authentication number. it changes the number every 60 seconds.

http://www.rsa.com/node.aspx?id=1156

I'm not sure this would ever be practical for consumers, but it's a clever idea. i've used it to get on vpns at big companies.

The problem with passwords is that ideally they are long random strings and different for every site. But humans are not good at remembering such passwords, so they tend pick shorter passwords and to re-use them on lots of sites.

But computers are good at remembering lots of long random strings, so why have we not developed a standard for site log-ons which the browser chooses the passwords and stores it securely for the user?

What's happening in the field of biometrics? Is it ever likely that I'll be asked to speak my name out loud and that'll work as reliably (from the user's perspective) as a password?

I've always thought, perhaps irrationally, that the problem with biometrics is false positives: i.e. letting in someone who isn't you. I misttype my passwords all the time, and I think users would be OK with a "Sorry, can you say that again?"-type message on occasion.

Basically, am I in "where's my flying car" territory?