Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Proof-of-concept public key authentication for web users

toolchain.eu

Post reply on HN
Print view View original

11–20 of 23 posts

Re: Proof-of-concept public key authentication for web users

#11

Post by thwarted »

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.

Re: Proof-of-concept public key authentication for web users

#12

Post by mmatants »

dekz wrote: post #4

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 o…

The big question is what kind of problem is being solved?

Truth is, nobody is giving up good old passwords just yet. Two-factor helps when necessary, but the password is still there.

The actual issue, IMO, is avoiding recovery of the plaintext passwords en masse when a typical website gets hacked. People reuse their passwords. So, as a webmaster, I don't want to be sitting on a pile of weak hashes, etc, etc.

Salted hashes like bcrypt seem to help (as far as I've read about these things). PKI offers even more potential.

E.g. a password-encrypted random keypair could be something - the client gets it at will from the server, decrypts it by prompting for password, and then uses it to authenticate a random nonce from the server.

Effectively, in that situation the server willingly gives up the entire authentication database, but trusts keypair blob's encryption to do its job against brute-force attacks.

Re: Proof-of-concept public key authentication for web users

#13

Post by markkum »

a3_nm wrote: post #8

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.

This is exactly what we are building here; 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.

Re: Proof-of-concept public key authentication for web users

#15

Post by Groxx »

redxaxder wrote: post #3
viraptor wrote: post #2

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

More info on client SSL certificates: http://www.gnegg.ch/2008/05/why-is-nobody-using-ssl-client-c...

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.

Re: Proof-of-concept public key authentication for web users

#16

Post by regularfry »

Groxx wrote: post #15
redxaxder wrote: post #3

Earlier quoted context omitted.

More info on client SSL certificates: http://www.gnegg.ch/2008/05/why-is-nobody-using-ssl-client-c...

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 wha…

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.

Re: Proof-of-concept public key authentication for web users

#17

Post by dekz »

mmatants wrote: post #12
dekz wrote: post #4

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 o…

The big question is what kind of problem is being solved? Truth is, nobody is giving up good old passwords just yet. Two-factor helps when necessary, but the password is still there. The actual issue, IMO, is avoiding recovery of the plaintext passwords en masse when a typical website gets hacked. People reuse their passwords. So, as a webmaster, I don't want to be sitting on a pile of weak hashes, etc, etc. Salted h…

> the client gets it at will from the server, decrypts it by prompting for password

That solution doesn't really solve the problems we're seeing all too often these days, user data being stolen and used. How do you determine who gets what encrypted keypair file, what's to stop an attacker from bruteforcing a persons keypair or even selectively attacking someone and decrypting their keypair. (I'm assuming you mean encrypted with a key generated from a PBKDF here).

Authentication is quite the hard thing to accomplish. BrowserID is a step forward for what we have today, but IMO it's not a step in the right direction, it's just moving the burden somewhere else.

Re: Proof-of-concept public key authentication for web users

#18

Post by a3_nm »

markkum wrote: post #13
a3_nm wrote: post #8

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.

This is exactly what we are building here; 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.

I was thinking of a standard. From your website, it seems that you are developing a product.

Re: Proof-of-concept public key authentication for web users

#19

Post by udoprog »

viraptor wrote: post #2

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

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.

Re: Proof-of-concept public key authentication for web users

#20

Post by mmatants »

dekz wrote: post #17
mmatants wrote: post #12

Earlier quoted context omitted.

The big question is what kind of problem is being solved? Truth is, nobody is giving up good old passwords just yet. Two-factor helps when necessary, but the password is still there. The actual issue, IMO, is avoiding recovery of the plaintext passwords en masse when a typical website gets hacked. People reuse their passwords. So, as a webmaster, I don't want to be sitting on a pile of weak hashes, etc, etc. Salted h…

> the client gets it at will from the server, decrypts it by prompting for password That solution doesn't really solve the problems we're seeing all too often these days, user data being stolen and used. How do you determine who gets what encrypted keypair file, what's to stop an attacker from bruteforcing a persons keypair or even selectively attacking someone and decrypting their keypair. (I'm assuming you mean enc…

So the server stores a keypair for the given account, and the keypair is encrypted with the account password. The keypair itself, once "unlocked" on the client-side, is then used to encrypt/decrypt a nonce at login time.

The inherent trait of this approach is that an attacker gets everyone's encrypted keypairs "for free", and can brute-force away. My hope was that the keypair's own encryption is more resilient to brute-forcing than a hash.

But that's very much questionable.

Post reply on HN