Hacker News Reader

Comment by nwh | Hacker News Reader

Just a thought regarding 2FA in general.

Why are people manually typing in keys? The authenticated website could just have an API with a receiving point for a token. A press of a button in a mobile app would unlock the login form for a short period just like a normal 2FA key, only with typing from the user.

You could use the numerical codes as a backup if the mobile device wasn't network accessible, but just being able to "push button" authenticate in a mobile app would make them a lot more usable normally.

Has this already been done, and I just haven't heard of it?

View on HN

Yubikey is sort of like this. It's a USB key with a small contact on it. It reports to the OS as a keyboard and when you press the contact is inputs a very long string of characters followed by an ENTER. So at the 2FA page you just press the USB key button and you get logged in.

Mt. Gox uses Yubikey for their 2FA.

I actually have two around my neck at the moment, I use them for my own hand-rolled websites. They're concienient, but just being able to push a button in an app would be even more so. Not to mention, the backend code they supply on their website is anything but pleasant.

Because its already stretching 2FA quite a bit to have it as just another program running on what is essentially a general purpose computer.

I can't quite see the difference between copying numbers out of an app, and sending a secure string to a server with HTTPS. If anything, doing it in the back end would allow for even longer strings. A signed message or a challenge-response with a large secure asymmetric key.

partly because this is a bit easier to implement, so the barrier to entry is lower.

Also, no network access is required for OATH TOTP tokens to work (they are derived from a shared secret and number of 30s segments of time since Unix epoch) if you are somewhere with no mobile coverage, or are abroad and don't want to pay roaming charges. You can also get hardware tokens for this reason.

Finally, there is no guarantee the network between your mobile device and the web app are secure, and as we've seen with some nation states abusing wildcard SSL certificates, even SSL isn't necessarily a defense.

Yeah, that's OneID and Duo Push, but no one uses it (yet). It's also proprietary, and I think there are some (stupid) patents.

Really, there's already x509, so if you're going to do this all on a single device (a single tablet or phone), just do client-side x509 certs managed well, plus passwords.

The problem was that desktop browsers had the worst possible UI for client certs, so no one used them, so desktop browsers had the worst possible UI for client certs, so no one used them, so ...

Duo Security uses this exact model for Duo Push. It's really pleasant to use.

Now thats more like it!

That's what we do with Claveo (http://www.claveo.com), but we use PKI instead of rolling codes so it's a lot more secure.

Reply on news.ycombinator.com