Why aren't we using public-key cryptography instead of passwords on the net?

[Deozaan]

I read a good essay/rant on passwords today, which was written/posted yesterday. Here's an excerpt:

When i do my hacker thing and connect to a server from a terminal/console/black box with letters in it, it uses public-key cryptography to prove who i am. I have a private key and a public key. The public key can be used to lock boxes in such a way that only my private key can unlock them again. I give out my public key; the server picks some big random number and encrypts it; if i can tell the server what random number it picked, then it knows i have the private key and must be who i say i am.

(Okay, that's still a bit oversimplified. The actual mechanism for how this usually works is pretty cool, if you want to read about it. It has a pretty picture using paint mixing.)

While my key is still protected by a password, the experience is radically different in a few critical ways.

• It's called a passphrase, not a password. And, indeed, my passphrase(s) tend to be phrases, 50+ characters long, decorated with punctuation in some way that makes sense to me. They're very easy to remember, yet i can't imagine how you'd even approach trying to crack them.
• I type the passphrase in once, when i boot up my machine. The private key is unlocked for the rest of the session, and it's used automatically when i connect to any server that has the corresponding public key. Logins are instant and seamless; i log in and out of stuff all day long.
• The passphrase stays on my machine. It's not sent to the server to be double-checked, like virtually all passwords on the Web are. Something like Firesheep simply cannot work; you can't sniff my passphrase out of the air if it's not there to begin with.
• Even if i connect to server A, and then hop from there to server B, i can defer all the key-checking back to my desktop. Server A doesn't need to have my private key on it to connect somewhere else in my name.
• You know those SSL certificate warnings? You know how you always ignore them? Yeah, you shouldn't do that. They're the only warning you get that someone might have hijacked the connection to your bank or whatever. It's a shame that browsers have trained most of us to ignore the warnings, because they're the only thing making SSL useful.
• Anyway, in the case of SSH: the server has its own public key, which it broadcasts to me as part of the login process. The first time i connect to a server, the public key is remembered on my machine. If i ever try to connect again, and the public key is different, the connection stops immediately. It's the same idea as the certificate warnings, except that public keys are supposed to last forever and you don't need to bleed cash to get one, so a changed key is actually a legitimate cause for concern. (Most SSL warnings are about a certificate that the website owner created himself, because getting a signed one is considerably pricey.)
• And best of all, i can use the same set of keys for any number of servers. Or i can use a separate key for every server. It's entirely up to me. It doesn't matter what my username is on each server. It doesn't matter whether the servers are related in any way. It doesn't even have to be my account; any account can have any number of public keys linked to it, so sharing an account is just a matter of giving it several people's keys.

I think it's a great read, and it even has a section on the stupidity of bank's websites almost requiring you to have an insecure password. Read the rest of it here. But be warned, it does contain some strong language.

I don't know much about encryption, but the essay seems to make some valid points and it makes me wonder why we use passwords instead of having a single private key to handle all that crap for us.

Mozilla is working on a solution called BrowserID, as discussed here, but as pointed out in the initial post, it is tied to your e-mail account, which isn't necessarily desirable.

So could someone--who presumably has more knowledge than me on this subject--tell me why we are using passwords for every single website we visit when we could just be using public-key cryptography to handle the details for us?

[Ehtyar]

Up until recently, browser compatibility. Same reason we're still using dedicated IPs for SSL instead of server name indication. However, I'd agree that there is no longer an excuse for either of these not being implemented.

Ehtyar.

[Renegade]

Oh god, I love this guy!

Quote - NSFW

Conclusion: everything is fucked and i hate computers.

Amen to that!

The guy hits so many things bang on.

For banks... Some of them should be charged with criminal negligence for their crappy security. e.g. A quote from him:

ING Direct: 6–10 digits

It gets worse... The Commonwealth Bank of Australia requires 6 digits and exactly 6 digits... Ahem... Perhaps they should be charge with criminal idiocy...

[rgdot]

What do you expect from a culture that requires signatures to pay but a copy of the signature is on the back (credit cards)? Then they put in a chip and require four digits...

[4wd]

It gets worse... The Commonwealth Bank of Australia requires 6 digits and exactly 6 digits...

WRT personal banking, it must be a different CBA you're talking about, the one I've used since they took over the State Bank of Victoria, (21 years ago), and that I've used NetBank with since it came out, (1997), have always allowed more than 6 digits....I know, my password has always been longer than 6 digits, (my wife uses an even longer password).
When I started using Netbank, a mix of alphanumeric characters wasn't mandatory but it was 2 years ago when my wife joined up, (it wouldn't let her create one that didn't have at least one digit and one character).

Your new password:

   must be between 8 and 16 characters long
   must contain both letters and numbers
   must be different to your previous 5 passwords
   should not contain a recognisable part of your name or your date of birth
   must not contain your NetBank client number
   can contain most characters except <>^`{}~=

Then there's your 8 digit client number to remember on top of that.

CBA Phonebank is the same, can be alphanumeric characters and longer than 6 characters.

And, if you're talking about ATM pins, then anything between 4 and 8 12 digits is fine, (mine is 8) - and that's been available for about 5 years.

Also, they'll send you a one off PIN via SMS when you try to pay a third party via NetBank for the first time or use a website that requires verification...providing you have that function turned on.

So, what particular service of CBA that requires exactly 6 digits are you talking about?

[f0dder]

I type the passphrase in once, when i boot up my machine. The private key is unlocked for the rest of the session, and it's used automatically when i connect to any server that has the corresponding public key. Logins are instant and seamless; i log in and out of stuff all day long.

And if public-key crypto became widespread, do you know what would happen? Yes, indeed, trojans attacking the keystore. If you keep the keystore authenticated all day, the encryption keys sit in memory all day, and every major OS has privilege escalation attacks that'll allow you to get at those precious bits.

Even if i connect to server A, and then hop from there to server B, i can defer all the key-checking back to my desktop. Server A doesn't need to have my private key on it to connect somewhere else in my name.

I really, really, really hope he only does that through servers he has 100% trust in. If server A gets compromised, funny things can happen to ssh agent forwarding.

But yes, all in all, good points - I certainly do prefer pubkey authentication to servers. (Oh, and remember not to use the same pubkey for everything).

[Stoic Joker]

I realize that encryption has its place in the scheme of security, But... I really thing it's overused as a magic bullet solution to the wrong problem. Computers today have the capability of spitting out thousands of password attempts per second ... And this is assumed as a complete justification for concocting passwords that are complex enough that (nobody can remember them) they will take "reasonably" close to a million years to guess. And the race begins...

Why...

Seriously, why even bother (joining the race) ... The computer can spit out x thousand attempts per second, which becomes completely and instantly irrelevant when a lockout policy is enabled. 5 attempts in a minute = locked out for x minutes. How successful is brute forcing against that scheme?? ...My guess is not very.

[Deozaan]

Seriously, why even bother (joining the race) ... The computer can spit out x thousand attempts per second, which becomes completely and instantly irrelevant when a lockout policy is enabled. 5 attempts in a minute = locked out for x minutes. How successful is brute forcing against that scheme?? ...My guess is not very.

Brute forcing isn't the only way to get someone's password. There's also phishing and other social engineering.

If all you relied on was a lockout policy and had something simple like "password3" as your password on every site you visited, that's still not very secure. Even if your password wasn't so stupid, a single breach on one site means all your accounts on all other sites are breached.

You'd still want a nice strong password that makes it hard to guess. Part of being a "nice, strong password" is that it isn't the same one for multiple sites/places. The hard part about having nice, strong passwords that aren't the same one on multiple sites is remembering them all. Hence public-key cryptography where you have a single nice, strong password the protects your private key which (if I understood it correctly) is then used to make a (bunch of) public keys which are each like nice, strong passwords that are hard to guess even with the lockout policy.

[Stoic Joker]

Seriously, why even bother (joining the race) ... The computer can spit out x thousand attempts per second, which becomes completely and instantly irrelevant when a lockout policy is enabled. 5 attempts in a minute = locked out for x minutes. How successful is brute forcing against that scheme?? ...My guess is not very.

Brute forcing isn't the only way to get someone's password. There's also phishing and other social engineering.

Which could also net the attacker the key ... No door is secure enough if "Knock Knock" works. But I leave that part up to Charles Darwin...

If all you relied on was a lockout policy and had something simple like "password3" as your password on every site you visited, that's still not very secure. Even if your password wasn't so stupid, a single breach on one site means all your accounts on all other sites are breached.

Agreed, no single layer is absolute ... I just get tired of all the stress being put on encryption. It does have its place but t's not a magic bullet, and sometimes simple really is best. Solutions that is, not passwords. The pass phrase idea I've always liked ... 25 character random strings is just begging for trouble.

You'd still want a nice strong password that makes it hard to guess. Part of being a "nice, strong password" is that it isn't the same one for multiple sites/places. The hard part about having nice, strong passwords that aren't the same one on multiple sites is remembering them all. Hence public-key cryptography where you have a single nice, strong password the protects your private key which (if I understood it correctly) is then used to make a (bunch of) public keys which are each like nice, strong passwords that are hard to guess even with the lockout policy.

A single point is a single point, the key can get accessed ... Especially if it a high value item. And if one needs to make it portable. Well... It either going to be memorable, or written down. Which take us right back to the getting hacked by the cleaning lady (I love that one).

[Renegade]

The pass phrase idea I've always liked ... 25 character random strings is just begging for trouble.

+1 for that!

[f0dder]

Seriously, why even bother (joining the race) ... The computer can spit out x thousand attempts per second, which becomes completely and instantly irrelevant when a lockout policy is enabled. 5 attempts in a minute = locked out for x minutes. How successful is brute forcing against that scheme?? ...My guess is not very.

...except when attackers get hold of the (hashed passwords | public key).

Throttling verification attempts (and blocking after too many, plus raising security flags) is a very good part of a security policy. But security is one of those things that require both breadth and depth.

You'd still want a nice strong password that makes it hard to guess. Part of being a "nice, strong password" is that it isn't the same one for multiple sites/places. The hard part about having nice, strong passwords that aren't the same one on multiple sites is remembering them all. Hence public-key cryptography where you have a single nice, strong password the protects your private key which (if I understood it correctly) is then used to make a (bunch of) public keys which are each like nice, strong passwords that are hard to guess even with the lockout policy.

One private key has one public key. What you do is protect your keystore with a single strong passphrase, and the keystore then has private keys for your various sites. Yes, it's a lot harder bruteforcing a public key that's large enough, but ideally you'd still use different keys for different sites (or at least partition so you have separate keys for very important stuff, one key for forums, etc.) - for the really-really important stuff, you could opt to not include that privkey in the keystore, and unlock it manually with a separate passphrase for every use.

Agreed, no single layer is absolute ... I just get tired of all the stress being put on encryption. It does have its place but t's not a magic bullet, and sometimes simple really is best. Solutions that is, not passwords. The pass phrase idea I've always liked ... 25 character random strings is just begging for trouble.

There's good reasons for focusing on (proper!) encryption, though, as it isn't just a means of authentication, it also helps a lot in regards to MITM attacks. SSL is hopeless in this regard - I'm not very confident in the CAs.

Of course the level of security required depends on the service offered. I have different demands depending on whether I'm accessing DonationCoder, my bank, or .gov services (the kind where identify fraud can really fsck with people's lives). Unfortunately, the powers that be in Denmark don't seem to grok this, and thus we're getting a fscking insecure (by design as well as implementation) "digital signature" system crammed down our throaths.

[iphigenie]

If I recall, the main obstacle to the widespread use of private/public keys was that it's ok between people who know each other and exchange it, but once you are starting to do it in a more widespread way with people and companies you dont know, how do they get your key, how does it scale? Need a distribution system with some kind of validation to prevent spoofing.

And the people who tried to offer this are the same who did the SSL certificates etc. and due to greed they set the prices stupidly. So it got stuck being used within the entreprise or between servers and old school geeks, but never got a chance to catch on.

I have a whole keyring of keys

[Stoic Joker]

Seriously, why even bother (joining the race) ... The computer can spit out x thousand attempts per second, which becomes completely and instantly irrelevant when a lockout policy is enabled. 5 attempts in a minute = locked out for x minutes. How successful is brute forcing against that scheme?? ...My guess is not very.

...except when attackers get hold of the (hashed passwords | public key).

Understood. But that's kind of a different (Typically SQL code security) issue. A way in is a way in, and once "they" are in...

Throttling verification attempts (and blocking after too many, plus raising security flags) is a very good part of a security policy. But security is one of those things that require both breadth and depth

Indeed, security is something that is practiced, not installed ... and that's one of the things I feel should be hyper stressed.

Agreed, no single layer is absolute ... I just get tired of all the stress being put on encryption. It does have its place but t's not a magic bullet, and sometimes simple really is best. Solutions that is, not passwords. The pass phrase idea I've always liked ... 25 character random strings is just begging for trouble.

There's good reasons for focusing on (proper!) encryption, though, as it isn't just a means of authentication, it also helps a lot in regards to MITM attacks. SSL is hopeless in this regard - I'm not very confident in the CAs.

Of course the level of security required depends on the service offered. I have different demands depending on whether I'm accessing DonationCoder, my bank, or .gov services (the kind where identify fraud can really fsck with people's lives). Unfortunately, the powers that be in Denmark don't seem to grok this, and thus we're getting a fscking insecure (by design as well as implementation) "digital signature" system crammed down our throaths.

Got no problems there I've actually been wanting to do a bit of research on the MITM stuff for a while now. I'd like to have a better understanding of the mechanics of exactly what is done and how these attacks work as they are indeed quite troubling.

[f0dder]

...except when attackers get hold of the (hashed passwords | public key).

Understood. But that's kind of a different (Typically SQL code security) issue. A way in is a way in, and once "they" are in...

Well, yes and no - systems aren't isolated these days. Most people use the same password(s) for multiple accounts. If it's breached (or lured away from you) once, an attacker typically has access to a lot more sites. Keep in mind that most schemes either
1) send password in plaintext (though trough SSL) to verify at the server side, while keeping a (hopefully ) secure hashed version server-side.
2) keep password in plaintext server-side, but can thus do verification without sending the password in plain (server sends hash of nonce+password, or similar).

#1 is vulnerable to MITM or fake site (DNS poisoning, very similarly named domains, injection attacks), #2 is 100%-game-over if the site is hacked but offers protection against #1 attacks.

With a pubkey scheme, attackers have a much more difficult situation - hacking the server gives them a "not in this lifetime bruteforceable" public key, MITM'ing doesn't work (not for the proper schemes - again, fsckyou SSL), and to do anything interesting they'd need to trojanize every individual target.

Got no problems there I've actually been wanting to do a bit of research on the MITM stuff for a while now. I'd like to have a better understanding of the mechanics of exactly what is done and how these attacks work as they are indeed quite troubling.

It's pretty scary for SSL. For a "criminal" MITM, you'd normally get a certificate warning, and most somewhat tech-savvy people would at least have a chance of avoiding this.

The scary part, however, is that governments have always had the capability of getting fake certs signed by a CA, and most people will not see this, because it looks legitimate. If you use something like Certificate Patrol for firefox, you'll at least see the cert has changed, and will get a warning if it happens long before old cert's expiry time. But other than that, a fake signed cert will look legitimate. And with the break-ins that have been recently at CAs, it's not only governments that have fake certs now.

If I recall, the main obstacle to the widespread use of private/public keys was that it's ok between people who know each other and exchange it, but once you are starting to do it in a more widespread way with people and companies you dont know, how do they get your key, how does it scale? Need a distribution system with some kind of validation to prevent spoofing.

Valid points - it's hard to do right, and you really need a web of trust or similar system... and even that isn't perfect if people just click "yeah yeah, sounds reasonable that this guy has updated his key" without veryfying by phone call or whatever.

There's a difference between requirements for web browsing and for "ensuring the identify of some random person you don't know" - for the web browsing part, I'd kinda prefer NO automatic trust over SSL's model. At least that way, as long as the first time I visit a server is without any MITM, I'll know if things are afoul from then on. (Unless of course a particular server has been infiltrated, but that'll only give the attackers control of my interaction with that server).

[Deozaan]

To add a little humor to this thread, here's a discussion we had in IRC a few days ago about this topic:

<Deozaan> Why doesn't the internet use public/private key authentication instead of passwords?
<Lashiec> because they're still working on that
<Deozaan> What do you mean?
<Lashiec> making it easy for everyone, I mean
<Deozaan> You can do that for e-mail, can't you?
<Lashiec> with something like this: http://www.donationcoder.com/forum/index.php?topic=27343.0
<Lashiec> PGP?
<Stephen66> biometrics would make life so much easie
<Stephen66> easier
<Deozaan> Not if you were undead!
<Deozaan> Because you know... undead don't have fingerprints...
<Deozaan> or retinas to scan
<Stephen66> why dont they have finger prints
<Deozaan> I dunno.
<Deozaan> For some reason I was thinking biometrics meant like having a pulse.
<Deozaan> But then I realized my mistake and so I started sarcastically making excuses as to why I was still correct.
<Stephen66> lol
<Lashiec> you can use the inflexion of their voice when they say "BRAAAAAINS" as a secondary authentication method
* Deozaan laughs.
<Stephen66> lol

[Edvard]

Banks... <shudder>
My default password scheme is a key-pattern mix of uppercase/lowercase numbers/special characters based on something in the name of the website I'm accessing (a Dvorak keyboard would seriously screw my world).
My bank doesn't allow special characters  
IBM Developerworks only allows special characters @#$%&*   IBM!!
The government jobs website allows special characters, but only certain ones, and it doesn't say which ones. 
There's no such thing as a paper job application any more, so I've had to sign up with a hundred websites, all of whom have differing password requirements (yeah, identity theft nightmare waiting to happen, but hey, I'm just a laid off schmoe begging for a spot on the payroll, what do they care?).

So, yeah, something needs to be done about the current username/password thing.
I'm all for whatever encrypted handshake thingamabob that needs to happen to make ID theft harder, but after reading everything I can stand about electronic security, I've concluded that your info is only as secure as the server it's stored on.

[capitalH]

To add a little humor to this thread, here's a discussion we had in IRC a few days ago about this topic:

<Deozaan> Why doesn't the internet use public/private key authentication instead of passwords?
<Lashiec> because they're still working on that
<Deozaan> What do you mean?
<Lashiec> making it easy for everyone, I mean
<Deozaan> You can do that for e-mail, can't you?
<Lashiec> with something like this: http://www.donationcoder.com/forum/index.php?topic=27343.0
<Lashiec> PGP?
<Stephen66> biometrics would make life so much easie
<Stephen66> easier
<Deozaan> Not if you were undead!
<Deozaan> Because you know... undead don't have fingerprints...
<Deozaan> or retinas to scan
<Stephen66> why dont they have finger prints
<Deozaan> I dunno.
<Deozaan> For some reason I was thinking biometrics meant like having a pulse.
<Deozaan> But then I realized my mistake and so I started sarcastically making excuses as to why I was still correct.
<Stephen66> lol
<Lashiec> you can use the inflexion of their voice when they say "BRAAAAAINS" as a secondary authentication method
* Deozaan laughs.
<Stephen66> lol

Truth be told, I am cool with the undead not being able to access anything on the Internet.

Banks... <shudder>
My default password scheme is a key-pattern mix of uppercase/lowercase numbers/special characters based on something in the name of the website I'm accessing (a Dvorak keyboard would seriously screw my world).
My bank doesn't allow special characters 
IBM Developerworks only allows special characters @#$%&*  IBM!!
The government jobs website allows special characters, but only certain ones, and it doesn't say which ones. 
There's no such thing as a paper job application any more, so I've had to sign up with a hundred websites, all of whom have differing password requirements (yeah, identity theft nightmare waiting to happen, but hey, I'm just a laid off schmoe begging for a spot on the payroll, what do they care?).

So, yeah, something needs to be done about the current username/password thing.
I'm all for whatever encrypted handshake thingamabob that needs to happen to make ID theft harder, but after reading everything I can stand about electronic security, I've concluded that your info is only as secure as the server it's stored on.

KeePass Portable to the rescue!

I just use the longest possible password allowed with as much special characters as allowed. I find it staggering to find the restrictions some websites have (6 digits? Really?)