3 ms·

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

by nwh 14y ago

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?

Osiris 14y ago
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.
- nwh 14y ago
  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.
dpeck 14y ago
Because its already stretching 2FA quite a bit to have it as just another program running on what is essentially a general purpose computer.
- nwh 14y ago
  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.
  - philjohn 14y ago
    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.
seanponeil 14y ago
Duo Security uses this exact model for Duo Push. It's really pleasant to use.
- nwh 14y ago
  Now thats more like it!
aclimatt 14y ago
That's what we do with Claveo (http://www.claveo.com http://www.claveo.com), but we use PKI instead of rolling codes so it's a lot more secure.
rdl 14y ago
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 ...

by nwh 14y ago

Osiris 14y ago

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.

nwh 14y ago
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.

dpeck 14y ago

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

nwh 14y ago
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.
- philjohn 14y ago
  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.

seanponeil 14y ago

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

nwh 14y ago
Now thats more like it!

aclimatt 14y ago

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

rdl 14y ago

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