15 ms·

Proof-of-concept public key authentication for web users

39 points by jlind 15y ago

viraptor 15y ago
How is that different from client certificate authentication? It seems strange that solution is not mentioned at all.
- redxaxder 15y ago
  More info on client SSL certificates: http://www.gnegg.ch/2008/05/why-is-nobody-using-ssl-client-certificates/ http://www.gnegg.ch/2008/05/why-is-nobody-using-ssl-client-c...
  - Groxx 15y ago
    I've been saying it to a lot of people for quite a while, but that's a very nice example: client certificates, OpenID, PGP, and a host of extremely-useful systems like those aren't hard because they're inherently hard. They're hard because their presentations are absolute crap. Take OpenID for example. I've encountered a bajillion nay-sayers, "it's too complicated" this and "too many steps for the user" that. So what's "sign in with Facebook" if not a better presentation of the exact same idea? And how many people have no problem using it every day? To have a security revolution, we need to have a security software revolution. The tech exists for the vast majority of problems, we just need to use it.
    - regularfry 15y ago
      Agreed. Even server-side, the software is awful - setting up a root-CA-signed certificate chain with the OpenSSL command-line tools (and java's keytool) is an absolute nightmare. Apart from anything else, it's astonishingly difficult to tell when you've got it right, and by extension, it's astonishingly difficult to tell when you've got it subtly (or not so subtly) wrong. This has nothing to do with the principles at play, and everything to do with how the information is presented.
- nodata 15y ago
  The terrible, terrible UI. Plus: the same problem as normal SSL certs: the registries aren't secure/trustable.
  - viraptor 15y ago
    UI is just an implementation part. If the main point was to improve on the user interaction side, I missed it completely. Only things he provided were an idea roughly equivalent to the existing one and a shell script which needs to be run outside of the browser. It's hardly better than "pick one entry from the dialog box", however ugly that dialog box is.
    - udoprog 15y ago
      No, the main point is to show how simple client verification actually is. This implementation is one step up on the application stack into a comfort zone which seems to be more acceptable by devs. I believe in design in depth, and by allowing the most basic of techniques (form submission + cli tool stack) to handle something that is generally perceived as difficult and letting people "get" the manual process, the automation might not seem as daunting. I did not intend to create a standard, just to provoke more discussion. I would however by gladly surprised if I woke up tomorrow and twitter allowed me to sign in by solving a challenge instead of a password : ).
- udoprog 15y ago
  Not so different in theory. This just displays how little fuzz client certification can be on a higher level which is more easily approachable by web developers.
dekz 15y ago
So you either require the user to somehow sync a private key across multiple computers (Including phones and tablets) or the can't access the site with this method. Do you agree on the digest, method, sizes? Do you blacklist md5, sha1? Does everyone agree to this or can I go to one site which uses an insecure algorithm and theres the potential for information to be leaked, which affects my usage of that private key on other websites. Do I have a private key for each different website? Do I then need something to manage this for me, ala KeyPass or 1Password? How do I authenticate with KeyPass or 1Password, with a password? We're back to where we started. I don't think PKI is the solution for this problem. BrowserID is moving in the right direction, I can trust Google to have appropriate security for my personal information, but as we've seen time and time again sites like gawker, mtgox cannot be. It would be nice to see a service like BrowserID catch on and I'd be willing to pay for a vendor for the service if they provide full disclosure on their method storing of my data. So I know they aren't storing in plaintext, hashing with md5, encrypting the passwords etc.
- pavel_lishin 15y ago
  Haven't all of your questions basically been answered in practice by the fact that keys are simple and effective when used to log in over ssh? Do you have a different private key per each server you log into, does a compromised server automatically render your keypair worthless, do you have software to handle keys now? Haven't your arguments been refuted by the simple fact that people use keypairs every day to log into servers easily and securely? The last time I had to type an account's password was when I had to run "sudo" on a test server.
  - tptacek 15y ago
    The first time you log into an SSH server, your connection is actually insecure (this is also true of every subsequent time you log in and see that yes/no dialog).
    - cosgroveb 15y ago
      Is there any way to be sure of an server's ssh fingerprint before logging in? You need to do that offline right? Maybe a PGP signed e-mail from the sysadmin?
a3_nm 15y ago
What we need is a public key authentication scheme with the possibility for normal users to delegate their identity to some trusted third party to which they hand their public key (like with OpenID). I think this would be the best of both worlds: normal users get a seamless experience, and nerds have total control over their identity without even needing to, say, own a domain name and trust DNS.
- markkum 15y ago
  This is exactly what we are building here; https://www.mepin.com https://www.mepin.com The private key is generated and stored in a smarphone or separate USB smartcard, so that normal users don't have to manage their private keys.
  - a3_nm 15y ago
    I was thinking of a standard. From your website, it seems that you are developing a product.
- jesboat 15y ago
  nothing prevents an openid provider from using cert-based auth now
thwarted 15y ago
I've been experimenting with something similar over the past couple of weeks, at the HTTP auth level (as that's my use case), although I don't have browser integration yet as I'm still working on interfacing to ssh-agent (also, insert standard lack-of-time excuse here). I've been experimenting with SSL client certs for a while. They don't have a decent UX/UI in any browser I've used (redxaxder provides a link in another thread) and are a significant hurdle to general adoption. We could maybe see significant process in this area if some well known, popular site, like Facebook or gmail, supported SSL client certificate authentication. We need to see more work in this area.

39 points by jlind 15y ago

viraptor 15y ago

How is that different from client certificate authentication? It seems strange that solution is not mentioned at all.

redxaxder 15y ago
More info on client SSL certificates: http://www.gnegg.ch/2008/05/why-is-nobody-using-ssl-client-certificates/ http://www.gnegg.ch/2008/05/why-is-nobody-using-ssl-client-c...
- Groxx 15y ago
  I've been saying it to a lot of people for quite a while, but that's a very nice example: client certificates, OpenID, PGP, and a host of extremely-useful systems like those aren't hard because they're inherently hard. They're hard because their presentations are absolute crap. Take OpenID for example. I've encountered a bajillion nay-sayers, "it's too complicated" this and "too many steps for the user" that. So what's "sign in with Facebook" if not a better presentation of the exact same idea? And how many people have no problem using it every day? To have a security revolution, we need to have a security software revolution. The tech exists for the vast majority of problems, we just need to use it.
  - regularfry 15y ago
    Agreed. Even server-side, the software is awful - setting up a root-CA-signed certificate chain with the OpenSSL command-line tools (and java's keytool) is an absolute nightmare. Apart from anything else, it's astonishingly difficult to tell when you've got it right, and by extension, it's astonishingly difficult to tell when you've got it subtly (or not so subtly) wrong. This has nothing to do with the principles at play, and everything to do with how the information is presented.
nodata 15y ago
The terrible, terrible UI. Plus: the same problem as normal SSL certs: the registries aren't secure/trustable.
- viraptor 15y ago
  UI is just an implementation part. If the main point was to improve on the user interaction side, I missed it completely. Only things he provided were an idea roughly equivalent to the existing one and a shell script which needs to be run outside of the browser. It's hardly better than "pick one entry from the dialog box", however ugly that dialog box is.
  - udoprog 15y ago
    No, the main point is to show how simple client verification actually is. This implementation is one step up on the application stack into a comfort zone which seems to be more acceptable by devs. I believe in design in depth, and by allowing the most basic of techniques (form submission + cli tool stack) to handle something that is generally perceived as difficult and letting people "get" the manual process, the automation might not seem as daunting. I did not intend to create a standard, just to provoke more discussion. I would however by gladly surprised if I woke up tomorrow and twitter allowed me to sign in by solving a challenge instead of a password : ).
udoprog 15y ago
Not so different in theory. This just displays how little fuzz client certification can be on a higher level which is more easily approachable by web developers.

dekz 15y ago

So you either require the user to somehow sync a private key across multiple computers (Including phones and tablets) or the can't access the site with this method. Do you agree on the digest, method, sizes? Do you blacklist md5, sha1? Does everyone agree to this or can I go to one site which uses an insecure algorithm and theres the potential for information to be leaked, which affects my usage of that private key on other websites. Do I have a private key for each different website? Do I then need something to manage this for me, ala KeyPass or 1Password? How do I authenticate with KeyPass or 1Password, with a password? We're back to where we started. I don't think PKI is the solution for this problem. BrowserID is moving in the right direction, I can trust Google to have appropriate security for my personal information, but as we've seen time and time again sites like gawker, mtgox cannot be. It would be nice to see a service like BrowserID catch on and I'd be willing to pay for a vendor for the service if they provide full disclosure on their method storing of my data. So I know they aren't storing in plaintext, hashing with md5, encrypting the passwords etc.

pavel_lishin 15y ago
Haven't all of your questions basically been answered in practice by the fact that keys are simple and effective when used to log in over ssh? Do you have a different private key per each server you log into, does a compromised server automatically render your keypair worthless, do you have software to handle keys now? Haven't your arguments been refuted by the simple fact that people use keypairs every day to log into servers easily and securely? The last time I had to type an account's password was when I had to run "sudo" on a test server.
- tptacek 15y ago
  The first time you log into an SSH server, your connection is actually insecure (this is also true of every subsequent time you log in and see that yes/no dialog).
  - cosgroveb 15y ago
    Is there any way to be sure of an server's ssh fingerprint before logging in? You need to do that offline right? Maybe a PGP signed e-mail from the sysadmin?

a3_nm 15y ago

What we need is a public key authentication scheme with the possibility for normal users to delegate their identity to some trusted third party to which they hand their public key (like with OpenID). I think this would be the best of both worlds: normal users get a seamless experience, and nerds have total control over their identity without even needing to, say, own a domain name and trust DNS.

markkum 15y ago
This is exactly what we are building here; https://www.mepin.com https://www.mepin.com The private key is generated and stored in a smarphone or separate USB smartcard, so that normal users don't have to manage their private keys.
- a3_nm 15y ago
  I was thinking of a standard. From your website, it seems that you are developing a product.
jesboat 15y ago
nothing prevents an openid provider from using cert-based auth now

thwarted 15y ago

I've been experimenting with something similar over the past couple of weeks, at the HTTP auth level (as that's my use case), although I don't have browser integration yet as I'm still working on interfacing to ssh-agent (also, insert standard lack-of-time excuse here). I've been experimenting with SSL client certs for a while. They don't have a decent UX/UI in any browser I've used (redxaxder provides a link in another thread) and are a significant hurdle to general adoption. We could maybe see significant process in this area if some well known, popular site, like Facebook or gmail, supported SSL client certificate authentication. We need to see more work in this area.