5 ms·
There's an interesting way you can implement TOTP that avoids the phishing problem described in the article. The method doesn't work for all situations, but it
by EB66 5y ago
There's an interesting way you can implement TOTP that avoids the phishing problem described in the article. The method doesn't work for all situations, but it works for many -- it works particularly well if all you're trying to do is protect access to a mobile app.
At my company we have a mobile app and we use TOTP for MFA. But instead of requiring a separate app like Google Authenticator to generate and type in 6 digit codes, we store the TOTP secret and generate the 6 digit codes all internally. In other words, we bundle the functionality of Google Authenticator directly into our own app.
From the user's perspective, it's wonderfully simple: the user scans a QR code on our website and they're instantly enrolled in MFA. Then for all subsequent logins, they just type in their username and password -- the 6 digit TOTP code generation is handled silently in the background.
With this approach you get all the benefits of TOTP-based MFA, but without the phishing risk. For all the mobile apps out there that offer TOTP as a form of MFA, I'm surprised how many of them require you to use a separate authenticator app.
- wepple 5y agoSo the TOTP seed is deployed to a specific users mobile app?
- EB66 5y agoYep, that's correct.
- wepple 5y agoReally fascinating idea I hadn’t heard of before. Felt “icky” at first pass, but it’s no different to having a separate TOTP gen app, in fact given it stops you from having to copy/paste the code around, possibly less exposure there. The only downsides I can think of is that if the app local data is exposed, you possibly lose your cached creds and the TOTP seed.. but most apps are toast if there’s a full local data exposure. I guess the other challenge is if you have to do a (full) app reinstall, you’ve got to re do the MFA config. But app reinstalls seem extremely rare these days (basically only when you get a new phone) Very fascinating idea
- EB66 5y ago> I guess the other challenge is if you have to do a (full) app reinstall Yeah, that's true, if the user does a full app removal and re-install then they would need to re-enroll in MFA. But for app updates they'd be ok. > The only downsides I can think of is that if the app local data is exposed, you possibly lose your cached creds and the TOTP seed.. That's a good point too, but what you're describing would probably require someone to fully compromise (root) a phone. If that happened, you'd be SOL on many fronts. At my company we try to safeguard against rooted phones by 1. only holding user credentials in memory and 2. pairing our app with a public key that encrypts the password as soon as it's entered (our servers then decrypt it with the private key upon receipt).
- nicoburns 5y ago> Yeah, that's true, if the user does a full app removal and re-install then they would need to re-enroll in MFA. But for app updates they'd be ok. How would they re-enroll without their MFA token? Surely the whole point is not to let them login without it?
- EB66 5y agoIt'd be the same process that you have to follow if you lost your phone and, along with it, all the TOTP seeds that were stored in your Google Authenticator. You'd have to go through whatever process the company requires to confirm your identity through alternative means and allow a re-enrollment in MFA.
- Johnny555 5y agoIs there any advantage of doing that versus just using a client side certificate to authenticate the device?
- EB66 5y agoI suppose that could work, but one potential advantage of TOTP is that the secret/seed used to generate the 6 digit codes is never transmitted and not at risk of being intercepted. It's also probably more user-friendly to put a TOTP secret/seed on a device than it would be a client certificate. A certificate would probably be too big to easily scan with a QR code. QR codes can hold large amounts of data, but with more data the QR becomes larger and the detail becomes very fine. The camera needs to be very good, lighting needs to be very good, etc.
- e12e 5y agoNeither is the key for a ssl cert generated on the device? In fact, with qr enrollment the 2fa approach does transmit/expose the secret (probably over https, but still).
- EB66 5y agoTrue, you can't generate a QR code without transmitting the TOTP secret/seed in some fashion, but it's a one-time event that's typically done over HTTPS like you suggested.
- Johnny555 5y agoJust as with normal server side TLS, the client doesn't send its private key (and it's not known to anyone but the client), so intercepting the certificate doesn't do the attacker any good. But if communications intercept is possible, even with TOTP the attacker could intercept the TOTP token for that session and use it to log in himself.
- nodamage 5y agoWhat happens when the user gets a new phone or deletes and reinstalls the app?
- EB66 5y agoThey would have to re-enroll in MFA, but that's the same thing that happens today if someone uses Google Authenticator and gets a new phone (or uninstalls Google Authenticator).
- nodamage 5y agoI'm not sure I understand. Aside from their password, does the user need to provide additional information to re-enroll in MFA on a new device?
- EB66 5y agoThat additional information would vary, but you basically would follow the same process for someone who loses their device (and along with it their TOTP authenticator app). You might send them a SMS code, require them to call in, etc. Basically it'd be no different than what companies already do today when someone loses their device and their authenticator app.
- psadauskas 5y agoHow does that work if the user logs on via a new device? (Or the attacker, knowing the user's password, does the same?)
- EB66 5y agoIf the user gets a new device then with this approach they would have to re-enroll in MFA.