Two-factor authentication for local applications: is it useful?
November 15, 2014 7:25 PM Subscribe
Google Authenticator. I see why it's useful where you're logging into a server that keeps some secrets. But why would it be useful to guard secrets that are stored on your own computer?
I'm thinking of one-time password two-factor authentication schemes, like the RSA SecurId token or the Google Authenticator application for mobile phones.
I can understand how it offers increased security for remote applications--that is, logging into a server. The authenticator app and the server have to communicate ahead of time to exchange some private key. After that, both the client authenticator app and the server application use the private key to generate the one-time code. If the user can't supply the right code, the server keeps its secrets.
Some applications, such as the Dashlane and LastPass password managers, also let you use Google Authenticator. Both these password managers store all of their data locally; though they do offer sync, all encryption and decryption happens locally.
What I don't get is how this possibly offers any increased security. Because the encrypted data is stored locally, this also means that the one-time password is stored locally--both in the authenticator app and in the application doing the decrypting (e.g. Dashlane). Wouldn't this mean that any determined attacker could break into (for example) Dashlane to get the secret key, and then use that to generate the correct one-time password? This isn't a problem when the data is stored server-side, as the attacker can't break into the server.
Is the one-time password for locally stored data just adding a hurdle for an attacker? Is it a worthwhile hurdle or a worthless hurdle? Does is really offer better protection than a strong password alone? And, why don't apps like Dashlane just allow you to use two passwords--one you type in, and another derived from a key that you place onto a USB flash drive? The USB flash drive key would not be stored on the machine. Wouldn't that be more secure than the one-time password, with only marginal additional hassle? (I'd say it's easier than typing in codes from a mobile app.)
I'm thinking of one-time password two-factor authentication schemes, like the RSA SecurId token or the Google Authenticator application for mobile phones.
I can understand how it offers increased security for remote applications--that is, logging into a server. The authenticator app and the server have to communicate ahead of time to exchange some private key. After that, both the client authenticator app and the server application use the private key to generate the one-time code. If the user can't supply the right code, the server keeps its secrets.
Some applications, such as the Dashlane and LastPass password managers, also let you use Google Authenticator. Both these password managers store all of their data locally; though they do offer sync, all encryption and decryption happens locally.
What I don't get is how this possibly offers any increased security. Because the encrypted data is stored locally, this also means that the one-time password is stored locally--both in the authenticator app and in the application doing the decrypting (e.g. Dashlane). Wouldn't this mean that any determined attacker could break into (for example) Dashlane to get the secret key, and then use that to generate the correct one-time password? This isn't a problem when the data is stored server-side, as the attacker can't break into the server.
Is the one-time password for locally stored data just adding a hurdle for an attacker? Is it a worthwhile hurdle or a worthless hurdle? Does is really offer better protection than a strong password alone? And, why don't apps like Dashlane just allow you to use two passwords--one you type in, and another derived from a key that you place onto a USB flash drive? The USB flash drive key would not be stored on the machine. Wouldn't that be more secure than the one-time password, with only marginal additional hassle? (I'd say it's easier than typing in codes from a mobile app.)
LastPass might store some data locally, but you can access it from anywhere else, whenever you want. I don't know how Dashlane works but I'm guessing it's probably similar. So I'm pretty sure the main purpose of the two-factor authentication is to prevent someone from getting to it from another device, not to prevent someone who already has access to your device AND your password from getting in.
posted by Sequence at 7:42 PM on November 15, 2014
posted by Sequence at 7:42 PM on November 15, 2014
By way of comparison, KeePass with a database file stored on Dropbox can also be accessed from anywhere, provided you have a way to get into your Dropbox account in the first place.
You can do that by keeping the portable Windows version of KeePass in USB memory on your keyring, along with a stub KeePass database file that contains only your Dropbox credentials and the master password for your main KeePass database file. That stub can double as the key file component for two-factor auth on your main database (KeePass doesn't care what kind of file you use for a key).
posted by flabdablet at 8:29 PM on November 15, 2014
You can do that by keeping the portable Windows version of KeePass in USB memory on your keyring, along with a stub KeePass database file that contains only your Dropbox credentials and the master password for your main KeePass database file. That stub can double as the key file component for two-factor auth on your main database (KeePass doesn't care what kind of file you use for a key).
posted by flabdablet at 8:29 PM on November 15, 2014
Sequence is right. The two-factor authentication is what protects the cloud sync part of LastPass. Without it, you can't download the encrypted vault from the LastPass servers. If you have LastPass set to store your vault locally for offline access, you don't have to use Google Authenticator to access your vault if it's been downloaded previously (see the bottom of this LastPass helpdesk page for more info).
By the way, there's no backchannel communication between a server and the Authenticator app. It's solely based on the secret key + the current time. As long as an Authenticator device (or anything else conforming to the TOTP algorithm) has the correct time, it can be used to authenticate, no network connection needed ever, even when doing the initial setup.
posted by zsazsa at 8:48 PM on November 15, 2014
By the way, there's no backchannel communication between a server and the Authenticator app. It's solely based on the secret key + the current time. As long as an Authenticator device (or anything else conforming to the TOTP algorithm) has the correct time, it can be used to authenticate, no network connection needed ever, even when doing the initial setup.
posted by zsazsa at 8:48 PM on November 15, 2014
Response by poster: OK, I see how LastPass's setup makes sense. Apparently LastPass will store and decrypt your information on a server.
Also, Dashlane apparently disables local storage when using Google Authenticator.
posted by massysett at 3:48 AM on November 16, 2014
Also, Dashlane apparently disables local storage when using Google Authenticator.
posted by massysett at 3:48 AM on November 16, 2014
Response by poster: Also, a good explanation on authentication versus decryption. Locally stored data needs decryption, not authentication, which makes two-step authentication mostly useless.
posted by massysett at 5:53 AM on November 16, 2014
posted by massysett at 5:53 AM on November 16, 2014
The one-time keys themselves are not persistently stored, but the pre-shared secret baked into their generator certainly is, and it is perfectly true that an attacker who gained access to that pre-shared secret could use it to generate successful TOTP authentications.
The manufacturers of TOTP keyring dongles typically go to fairly extreme lengths to prevent those pre-shared keys being extracted from their hardware. Purely software-based TOTP authenticators, it seems to me, would be much less difficult nuts to crack, given physical access to the device they're on.
But that physical access is required. There's no way for software installed on a compromised computer, for example, to retrieve the pre-shared TOTP key from either a keyring dongle or a phone running Google Authenticator. Just don't expect a TOTP authenticator to provide you with genuine two-factor protection when it's running on the very same device you're using it to authenticate.
posted by flabdablet at 11:22 PM on November 16, 2014
The manufacturers of TOTP keyring dongles typically go to fairly extreme lengths to prevent those pre-shared keys being extracted from their hardware. Purely software-based TOTP authenticators, it seems to me, would be much less difficult nuts to crack, given physical access to the device they're on.
But that physical access is required. There's no way for software installed on a compromised computer, for example, to retrieve the pre-shared TOTP key from either a keyring dongle or a phone running Google Authenticator. Just don't expect a TOTP authenticator to provide you with genuine two-factor protection when it's running on the very same device you're using it to authenticate.
posted by flabdablet at 11:22 PM on November 16, 2014
« Older Wrinkle cream advice for an ageing old bag ;-) | What do I do for 10 hours in Singapore/Changi? Newer »
This thread is closed to new comments.
The main threat that two-factor auth protects you against better than a strong password alone would do is key loggers.
If you want a well-respected free local password manager that lets you set up genuine local two-factor auth (knowledge of a password + possession of a key file), try KeePass. There are various sync plugins available for it but simply keeping the authoritative copy of your passwords file on Dropbox works fine.
posted by flabdablet at 7:34 PM on November 15, 2014