Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Sounds like you actually want client certificates.

If only our ancestors didn't so royally screw that up.. they took the brilliant public-key crypto and even just through the bazillion different encoding schemes and various "cert store" madness have made its use entirely untenable. The whole "the service can't know the password" problem was entirely solved and look where we stand today.



Are they still working? anyone ever used it as auth method?


The foundation is solid. The UI is terrible and browser vendors don't do anything about it (sort of catch-22 here)

A sane certificate management UI (not hidden beneath 5+ clicks, and not full of useless distractions like "software security token" that scare users away), key escrow protocol (opt-in), transparent certificate sync (yes, has downsides, but no worse than password sync), and some JS APIs to manage certs - that can do miracles. But that won't happen.


That will happen - truefactor.io


Sorry, this doesn't look attractive to me. Among the downsides I see, the important one is that it requires a whole new software stack. That had been tried many times - I'm afraid, unless you have some really huge corporation backing the project (one that can really push it), it just won't fly.

What's good about TLS is that it's ubiquitous and you don't need anything special to deploy it. Got nginx, Apache or Caddy? Add a single directive (e.g. ssl_verify_client for nginx) and you're almost there, all the validation is already implemented, just tie the keys to your accounts system.


That software stack is made to fix previous problems. Backed up as a password, deterministic and scales easily.

It is new (tiny and well thought through) API but nobody used client certs anyway, as we found out in this very thread.


It was used on startssl.com, at least before they got in cahoots with wosign and subsequently got de-listed as a CA for various shady practices. I haven't checked since.

Also, I think Chrome is in the process of removing support for <keygen> (and client side certificates in general?), so whatever opportunity existed for making this common has now passed.


I remember this on startssl.com, and experience (or at least Firefox's implementation) was horrible.

-I had to refresh certificate once per year, which is very inconvenient, as I would go to startssl.com once per year total

- Half of the time something would go wrong with keygen in firefox and it would not remember my certificate at all. This is when you discover that all the security is simply bypassed when you send email to support.

- And worst of all, it was not very secure at all -- a malware on my computer would totally steal a certificate and keysniff the password for it. Compare with Google Authenticator or SMS auth, where I would be safe as long as my cell phone is not compromized at the same time.


True, the implementations were lacking some finesse. But a proper keychain type cert store handled by the operating system should in theory be able to protect the certificate against usermode malware (perhaps by only coughing up the certificate to an application signed with the same code signing ID as the application that inserted the certificate, and/or after an elevated password prompt)


The behaviour you describe here is how Keychain works on macOS.


It was used on an IE-only project I worked on many years ago. It was very difficult for users to manage and was used in addition to individual credentialing with a username/password. The certificate would identify the physical location, so there'd be one per client installed onto all the machines from which the site could be used.


Ah, no wonder it's dead.


Chrome blocked client certificate generation by default from version 49, I think you have to enable it specifically now and in general the process is messy (difficult to tell if your private key info is lost or where it ended up).

Firefox still works. No idea if people use it for auth, but it is popular when requesting a certificate.


I've used it for internal (internet exposed due to remote) services before - works in ff, the only issue I've had is remembering them


the rng in js is not good enough for crypto. but if you send the cert including key to the browser most browsers know what to do and will auto use it. there are different formats for different browsers though. and the server also needs to have a cert


You could have used <keygen> (when it was still implemented in browsers) and avoid performing any crypto maths in JS. :)


MIT does (did?)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: