Hacker News new | ask | show | jobs
by peterwwillis 4458 days ago
If I remember correctly, a browser add-in using TOTP could remove this as a viable attack method. By the time the user's one-time-encrypted login token is sent to the server it's been invalidated after login, and a new token is required, so siphoning off durable creds from memory becomes useless. However, you can still skim sessions.
3 comments

Session skimming is definitely still viable, and is especially bad if the compromised service doesn't require an escalated / different session to disable 2FA.

Additionally, there's a chance an attacker could compromise the TOTP secret as well as it will probably be in memory around the same time (unless the system is using a keyserver or HSM). At that point, the whole setup is blown and the user's credentials could presumably be replayed.

If I understand it all correctly, wouldn't the secret key exchange have been potentially exposed as well? It had to traverse some medium from server to client (or in reverse) at some point, so an attack could plausibly have account information as well as TOTP secrets to perform full two-factor authentications in perpetuity, no?
It's worse than that. Since the server has to use the TOTP key/secret to generate the token for validation, there's a very high chance the secret will be in the server's process memory at around the same time as the first-factor credentials are, unless a separate keyserver or HSM is in use. This applies on every login, not just during the initial TOTP exchange / setup process.

Thus, the key exchange doesn't need to be exposed for heartbleed to have a good potential to leak TOTP/2FA secrets.

Well I suppose you're right, if you're using your bastion host as the TOTP operation service provider, but I wouldn't recommend that for a whole host of reasons - the main one being that the bastion host is always the first host exploited, so you shouldn't be running anything from there but a proxy.

You should be able to simply move the TOTP operation to an authentication server on a more secure network and have your web-application server query it with the user's token. The web app will get back the result of the operation and never expose the secret key to the bastion host.

Say I'm logging into flickr.com with my Google account - what's at risk in that case?