Hacker News new | past | comments | ask | show | jobs | submit login

They're not insane though. Client certs, like ssh keys, aren't the whole storey. Users don't use the same browser all the time. How do you move a cert securely? How do you "move" a cert at all given that peer-to-peer transfer between devices basically hasn't worked for common users since the end of the floppy disk (seriously: try asking your aunt to copy a big PDF file from her computer to her iPad without broadband).

Someone needs to do this in the browser. You'd need to put a (escrowed!) keyphrase on the cert, back it up to the cloud securely, associate it with the user's account in such a way that they can get to it. And then enough browsers need to support it to make it worthwhile. That's a tall order.




Technically you should not be moving certs. Each machine should have its own cert that the bank can choose to invalidate or not. It simply hooks in to the first time process of identifying a user/device.

For example many banks in the US use security questions to identify a user/device on first run. In europe they use randomized keycards. Once this has been completed the device stores a nonce to identify the device across multiple sessions. If you ever kill your nonce you have to repeat first time authentication.

Now granted this works, and many people might feel this is good enough, but I agree with the author that client certs would work better for identifying users then the current solutions.


you never move a cert, just like you never move an ssh key. you simply generate a new one and add it to their auth, any time the user is using a new browser they have to go through extra authentication steps, and get issued a new cert for their browser (or not, on a public machine).


"any time the user is using a new browser they have to go through extra authentication steps"

And one wonders why no one wants to do this stuff.

This is poor analysis. You're arguing from an incomplete position. The choice isn't between "some security" (mobile certs) and "best security" (forced reauthentication). It's between "bad security" (multiple accounts with shared passwords) and "better security" (single cloud account with escrowed access to the cert).


The two major public banks in Brazil require clients to provide additional information if you are on a "new" PC. One of them asks personal information (id numbers, etc), the other sends an SMS to your cell phone and you enter that number (a very good two-factor auth).

They don't use client certs, though, and I have no knowledge on the private banks.


Usually what are the ways to authenticate the user when generating a new cert?

A user moving to a new browser has to identify himself as the real user, thus requiring some sort of authentication. It's a chicken and egg thing.


Automated call? Automated text?


an emailed code is usually the prefered method, however depending on your needs a text message or account details may work


So in this case an SSL cert is just like a cookie. Why not just use two factor (SMS or an app) when there is no cookie?




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

Search: