[PaperclipTaken]

There is a solution that is easier than auditing, found within the public key system. You could use the same password for every single website without any of them ever knowing what it is. You would instead associate your account with a public key and then use it to verify your identity every time you wanted to log in.

Then, the only vulnerability is your local machine. If someone hacks a website, the only password related information they can access is your public key, but you tell that to everyone anyway. They won't be able to use that to log onto any other website, even though you use the same password for all of them.

You would still probably want to use multiple public keys, and two-factor authentication (to eliminate the single-point-of-failure risk), but the technology already exists for us to be doing this. It just needs that extra layer that will make using such a system easy for grandma, and then of course for websites to start accepting public key authentication instead of password authentication.

edit: http://en.wikipedia.org/wiki/Public-key_cryptography

[1qaz2wsx3edc]

It kind of saddens me that the W3C is willing to focus on things like DRM, but not a public-key implementation for browser vendors. Yeesh.

[0x0]

Well, there is always the html5 <keygen> tag?

http://www.w3.org/TR/html-markup/keygen.html

https://developer.mozilla.org/en-US/docs/HTML/Element/keygen

[nly]

What!? No demoscene music in my <keygen> ?

[Flimm]

SSL includes a feature called client-side certificates: http://pilif.github.io/2008/05/why-is-nobody-using-ssl-clien...

[drdaeman]

Actually, there's a W3C WG that works (worked?) on a protocol called WebID, that uses public keys to authenticate users, and servers are not identity providers but just serving profile information.

http://www.w3.org/2005/Incubator/webid/spec/#authentication-...

[nly]

You're describing SRP. The problem, as always, is getting web browsers and web apps to support it.

https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

https://en.wikipedia.org/wiki/TLS-SRP

[loceng]

So the execution is failing..

[mpyne]

If IIRC it's also software-patent-protected, which is severely hampering deployment across the greater Web.

[jenandre]

The solution isn't intended as a measure to resist intrusion, I agree 100% with you that using PKI as a form of two factor for hardening authentication is a great idea.

It's more of a secondary measure for forensics and incident response purposes when the intrusion resistance measures fail. If your credentials can be hacked for any reason(your key AND your password are compromised, for example), when those credentials are used you have a useful audit trail of when it happened and can possibly even get some early notification. If I hack your laptop and use your valid credentials to log in to a site, even if you log in just to disable the audit logging, there will at least be one entry of that happening somewhere. If the audit collection system supports some early notification, you can potentially change your credentials or notify the service before the hacker does something bad.

[aapl]

One issue with just using a public key everywhere is that the most common public key authentication protocols result in some degree of non-repudiability. This is desirable for signing in to a bank but not for potentially embarrassing sites. I guess the cryptographic community might already have an answer to this, though.

[tonfa]

Different public for every site (which is what google proposed: http://www.computer.org/cms/Computer.org/ComputingNow/pdfs/A...)

[pi18n]

Simple and effective. I hope Mozilla is working on something like this, their recent updates have included some great defaults for privacy and security; this might fit in with their browser as authentication idea and be more secure than using email as the backend.

[callahad]

Mozilla Persona is all public key crypto under the hood. Learn more and help out: http://developer.mozilla.org/persona

I also gave a talk at PyCon covering the why, what, and how of Persona, if you prefer that medium: http://pyvideo.org/video/1764

(For what it's worth, the docs need another round of polish but they should get you started. If you have any questions, please feel free to email me directly.)

[drdaeman]

Persona users' keypairs are ephemeral, and their use just to provide temporary (in practice, usually, one-time) assertion from an identity provider that you have authorized with them.

[callahad]

Yeah, I hear you. Persona isn't public-key-utopia, but I do think it moves us to an unambiguously better place. The protocol is built so that users who want more "advanced" authentication schemes, like client-side SSL certs, can have them. Seamlessly. But everyone gets a better risk profile, even in the common case.

[drdaeman]

My biggest problem with Persona, is that I don't own an identity. My identity is provided to me by some third party. Even if I host an identity provider on my physically owned server, the identity is still not mine, as I can't own a domain (domains are leased from a registrar, not bought).

It also does not solve many problems OpenID had. For example, multiple identities ("which provider did I use here?") got even worse and migration is still completely manual (go everywhere, tell them you have new email, good luck if you already don't have the old one) and, rephrasing the OP title, "I long for the future where I can safely assume my email provider is compromised" is impossible with Persona, too. The point is, I believe, the Persona already has known design-level problems and, I guess, will eventually go away, replaced by something else.

And I don't really understand why we need such steps and finally get to the point we are the source and are in possession of our own identities, and others are just trusted third parties that are asserting our descriptions of ourselves. Standardize an secure key escrow (sync) protocol, think about UI/UX issues (present-day browsers HTTPS certificate UI is plain ugly), have some advertisement and educating articles and that's about it.

(Added after some thinking) Well, maybe I'm oversimplifying it, though, and things are harder than I believe they are... But the only problem I ever had with GPG (which I used as identity system) is key loss and temporary unavailability. And this could be really mitigated by key escrow (trading a bit of security for usability).

[arvidj]

We use something like this called BankID[1] in Sweden to log in to banks and to several other governemental agencies.

[1] http://www.bankid.com/en/what-is-bankid/

[Zash]

BankID is using pretty standard public key crypto with a custom API. http://wiki.fribid.se/ has some docs on how it works (in swedish).

[akkartik]

But that requires sites to not be bozos, to deal with a more complex cryptosystem. If we could achieve that then we could just get them to do the damn hashing right.

Here's a simpler solution: integrate password managers with modern browsers out of the box. Each site I log on to gets a hash of my password with their domain. But I need to install an extension to get this. Just make it more accessible. It doesn't matter if you use sha-1 or md5; it'll get everyone to use high-entropy passwords, and to not reuse passwords across sites. It'll be strictly better (by orders of magnitude) than the current situation.

[danbruc]

This does not improve the situation much - if your password is weak it is still easy to recover using a dictionary attack - just compute hash(salt + hash(password + domain)) for common passwords until you find a match in your compromised password database. As long as the only secret is the users password and this password is weak, you are out of luck whatever you do.

On the other hand if your password is strong, then it is very unlikely that an attacker is able to recover it even from a plain unsalted MD5 hash. The only thing gained is protection of reused not-to-weak passwords in the case a system storing plain text passwords gets compromised.

[akkartik]

Ah, I see your point. Whereas if people with unsecure passwords saw others logging into their accounts they might be more likely to change their habits. I stand corrected.

[tripzilch]

> But that requires sites to not be bozos, to deal with a more complex cryptosystem. If we could achieve that then we could just get them to do the damn hashing right.

Not quite.

If a site gets the damn hashing wrong, a successful attack means that your password is now open on the streets.

If a site gets asymmetric crypto wrong, a successful attack means that particular account/site is now compromised, but your pk is still completely private, because you never send it over the network in the first place, bozo site or not. (now if the client is a bozo and allows the pk to be sent across the network, then yes ..)

[dredmorbius]

No: you hash the master password, locally, and use that hash as the value you provide the remote site.

Now, they should also hash the hash, so that should it be know, your account on that site and that site alone cannot be compromised. But your master password is safe.

One of the problems with a scheme such as this is sites with multiple subdomains that use the same account per user. I'm thinking of Stack Exchange and Slashdot, for example. So simply using the hostname to generate a hash won't quite work.

But either this or the PKI method would be vastly preferable to what exists today.

For myself: I've been generating unique, per-site passwords for the past decade or more, and saving those in an encrypted database. Multiple copies of that spread around to prevent loss of access in the event of any single system going down. But otherwise: secure.

[akkartik]

My point was that if we could change every site on the internet to use public keys we wouldn't be having this conversation because they'd already be doing the hashing right with bcrypt.

Sure you can get some sites to use it, and sure you can come up with some way to secure a few savvy people. But it wouldn't elevate ambient security if you expect every site on the internet to change.

Instead my proposal would start securing 80% of the internet by fixing three codebases.

[andrewaylett]

How do you change the password for just one of your sites after said site is compromised?

[switch33]

This is a good idea; but if your single computer is hack'd that is just as bad as if someone just got on your computer when you were just walking away and you were still logged in.

It makes identity and account problems just as problematic.

I actually like the auditing idea; however I think he goes a bit overboard about having GeoIP for every single login because I know many people log in from tons of different locations all the time.

Maybe a more simpler alternative would work; but it needs to be well thought out for sure.

[6d0debc071]

IP checking's not necessarily going to help. If I get your passwords, I'm going to try them with every site I know about in a matter of seconds.

Public key crypto does seem to be a better solution - I've heard it proposed a number of times among security people now. And it has some nice features even when you assume that user computers are still vulnerable to attack.

• It seems to be a harder problem to hack all the users of a service than it is to hack the service itself

• If you abstract the public key stuff into the browser nothing would change in that regard. You can use different passwords packaged with your key. Personally I don't think it's worth the bother if you assume that people tend to use the same passwords but... whatever.

• You could do all the crypto on a token and use interface controllers to reduce your attack surface there.

The difficult bit, as far as I can tell at the moment, is that it requires people to know that there's a file they need to keep safe if they want to hang onto their accounts. I really think you'd need a physical token to get it down to the level that many people are capable of understanding, and then you'd better pray they don't lose it....

If we're gonna trend that way, we add complexity - and that's not going to get people to adopt.

[tripzilch]

> but if your single computer is hack'd that is just as bad as if someone just got on your computer when you were just walking away and you were still logged in.

Computer security usually starts out from the assumption that physical access to the machine == completely vulnerable, whether you were logged in or not.

[drdaeman]

You can always buy a hardware security token, which gets the key and never ever releases it away.

Hacked computer will mean, the attacker will be able to sign authorization requests (if they know the password for the token) just while they have access to your computer. Fix the security issues and you're safe again.

[mef]

She.

[betterunix]

https://en.wikipedia.org/wiki/Smart_card

[pbreit]

How does that work on other machines, mobile, Mint, etc.?

[halviti]

Certificates are supported out of the box on every operating system I can think of dating back at least 15 years.

[addandsubtract]

How, in the practical sense, does this work on other machines then? Am I supposed to carry my public key around with me everywhere, and load it on my friends mobile device just to check my email?

[maxerickson]

The dreamy eyed answer to this is that you would have your private keys on your phone and other devices would be able to ask it to verify a token. As seamlessly as possible and/or sensible.

[betterunix]

This is a solved problem, we just are not bothering to deploy the solution:

https://en.wikipedia.org/wiki/Smart_card

[pbreit]

How does a smart card help? So every device would need to be able to read a smart card? And third parties would need to be able to accept, store and present whatever is on the card?

[betterunix]

Yes, every device would need to be able to read smart cards, and everyone would need to have smartcards. Other than the card, everything would just look like normal public key authentication; third parties would not need to store anything other than what they would store if this were done entirely in software.

[antninja]

PasswordMaker works a bit like that, although in a much more lightweight way, making a hash of the site's domain name + the master password you enter each time. The downside is that it doesn't easily work everywhere due to stupid rules like "your password must/must-not contain punctuation".

http://passwordmaker.org/

[sskates]

Doesn't storing a hashed and salted version of a user's password accomplish the same thing as storing a user's public key? I suppose the other advantage of doing this is it's easier to do without the password leaving your machine.

edit: I should have added it's equivalent to requiring a password of a certain length.

[sillysaurus]

Doesn't storing a hashed and salted version of a user's password accomplish the same thing as storing a user's public key?

No, because a public key can't be reversed into a private key. A hashed and salted version of a short-enough password can be reversed (sometimes trivially).

[sskates]

In both instances it depends on the length of the secret you hold. If your private key is small enough you can brute force it as well. That sounds like it's equivalent to requiring a password of a certain length.

Now that I think about it, you also need to make sure that your hashing mechanism is preimage resistant, which is an additional place to make a mistake, so public keys do have an advantage there.

[pi18n]

I think asymmetric keys have the advantage that, you could sign some token that includes the website name, so a phishing or XSS attack would work against one website at a time. In fact, if the token was something authenticated by the server's certificate and included the destination IP, the true website might be able to reject false signed tokens that weren't done via MITM.

[gingerlime]

and also, the user has to send the cleartext (unhashed) password to the website to login every time, in which case it can be intercepted.

Whereas with public key authentication you don't send the private key, you 'prove' that you have it by performing a challenge typically.