Hacker News Reader

Comment by seanalltogether | Hacker News Reader

I have now built 5 mobile banking apps for iOS / Andrdoid for 4 different clients. We have proposed this as a security measure to every app we've built so far. It is a perfect solution since many banks can now identify the user and ensure the the traffic is really coming from them. It also helps that since we're building custom apps, we don't have to rely on simple cookie+ssl based solution.

Guess how many companies bite? Zero. None of them want to do it, and these are major nationwide banks. So much of their knowledge comes from handling browser based sessions that they can't imagine a different way.

View on HN

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.

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).

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

"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.

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?

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.

Banks in the U.S. have been largely content with username and password security, perhaps because their sites don't let you do all that much -- at least so far. Now, with more p2p functionality coming (esp. cross-bank; see clearXchange), that might need to change in a hurry. Some banks (like Wells Fargo) do phone number authentication before executing some actions (like p2p payments). https://www.wellsfargo.com/privacy_security/online/advanceda...

At Clover (www.clover.com) we've built a payment app for iOS and Android which use client certs to great effect. Once your iOS/Android device is bound to your Clover account using the client cert, you just need a short PIN to protect against unauthorized physical access to the device.

Because we're a native app, we're able to hide all the nastiness of installing the client cert. When the app is freshly installed, we first verify control over a phone number (by sending a text or calling it with a verification code). If that checks out, we issue a new client cert to that device and associate the device with the account bound to the phone number. An account is locked to a (small) set of devices (e.g. iPad + iPhone).

Reply on news.ycombinator.com