6 ms·
I'd rather deal with resetting OATH 2-factor tokens, than rely on proprietary apps like duo or authy, or rely on the security of mobile networks (for SMS). Tha
by harshreality 14y ago
I'd rather deal with resetting OATH 2-factor tokens, than rely on proprietary apps like duo or authy, or rely on the security of mobile networks (for SMS). That complication is an unavoidable consequence of not relying on trusted third parties (like authy or duo), right? Apps like those also encourage fracturing of the 2-factor ecosystem, rather than relying on a single standard.
I realize that corporations with lots of employees to support see things differently, and centralized 2-factor proxy in that environment makes more sense.
The only problem I have with google authenticator is that it's barely maintained. Even obvious features like rearranging order of accounts, haven't been implemented.
http://code.google.com/p/google-authenticator/issues/list?can=2&q=&sort=-stars http://code.google.com/p/google-authenticator/issues/list?ca...
Although they could add some export functionality, that would be a problem, now that I think about it, because anyone with even brief access to your phone could export all the OATH seeds to their phone.
- stock_toaster 14y ago> The only problem I have with google authenticator is that it's barely maintained. Even obvious features like rearranging order of accounts, haven't been implemented. http://code.google.com/p/google-authenticator/issues/list?ca.. http://code.google.com/p/google-authenticator/issues/list?ca.... There is also a weird bug in google authenticator (on ios) where the edit button in the lower left doesn't work until you hit legal information button, then go back. Very weird.
- rdl 14y agoActually Google seems to have fixed the one issue I really cared about; it's possible to create a new device (and then manually use the new code to put the app on both iPhone and iPad) without turning off 2-factor-auth entirely. But they don't actually check that you have the 2 factor device when you do this, so all you need to do is get logged in once and you're clear to lock the original user out, change auth credentials, etc. It's totally fine for the "protect a personal gmail account" threat model, but as far as I can tell, no one does 2fa in a way as-secure as I'd want it for an enterprise/IT deployment.
- stock_toaster 14y ago> Actually Google seems to have fixed the one issue I really cared about; it's possible to create a new device (and then manually use the new code to put the app on both iPhone and iPad) without turning off 2-factor-auth entirely. Interesting. I have been using 2fa for a while now, and hadn't noticed this yet (guess I don't view that page often). It seems they rely on someone needing to know the password and the generated pin to get to that point (or the pre-generated backup codes -- which are also not invalidated with the new 2fa replacement). > But they don't actually check that you have the 2 factor device when you do this, so all you need to do is get logged in once and you're clear to lock the original user out, change auth credentials, etc. I don't see how this is different than it was before. If someone gets your password and a valid 2fa pin or pre-generated code (eg. they can log in), they could just change your password, turn off 2fa, etc. Your aren't getting in then either.
- rdl 14y agoIf you have a computer saved as "trusted", it doesn't require the dongle. I'm pretty sure people usually save their primary computer as trusted, so all this takes is an unlocked browser with potentially saved password for Google (not unreasonable, given how often people log into google services). There has to be some happy medium between 100% trusted computer (including admin pages) and untrusted computer (PIN every 30 days or every new Google service login...). I'd probably start by always requiring PIN for the admin page, particularly for features related to removing or changing the authenticator, even if the user is on a trusted computer. What I want is a system where only momentary access to all login credentials normally used for a login (password (saved in browser?) and 2fa device) is enough to log in once, potentially lock out the authorized user, but not to have permanent access. With a "real" token, at least in most enterprise systems, a normal user can't remove the token from his account. So you'd be able to log in once, maybe reset the password, but couldn't change the token or remove the need for a token. I'd be fine with a system where removing 2fa was a big procedure, same as the lost password recovery should be (i.e. more than just one email). Maybe just requiring a 72h wait (after emailing you and a trusted designee?) where anyone could complain to stop it and escalate to humans? There should be a "low trust path" way to lock someone out of an account (with minimal authentication), so if you lose your token it can be locked, which sucks, but being unable to check your email for 12-72h in the interim might be an acceptable compromise. All of this should be configured when you open the account, or as you rely more on the account, in advance of an actual breach. I guess what I really want is an Internet login system which assigns different levels of trust and trust requirement to different actions, not the current basically binary system. Something more similar to credit (less checking for small amounts, repeated transactions, etc. than for a new mortgage). Amazon sort of does this (they have at least 4 levels; un logged in, sort of logged in on a machine without 1-click, logged in enough to make purchases to existing addresses, logged in in last 5 minutes or so to edit details). However, Amazon is light years ahead of everyone on a lot of things related to ecommerce, and it's not trivial to figure out how this should work.