[bri3d]

In this attack, data from the server process's address space is sent back to a malicious client.

Yahoo hopefully/presumably store only password hashes at rest, but just as in almost any system the user's real, clear password has to be sent from the user to the server to hash and verify against the database in order for the user to log in. Yahoo were following best practices by sending this password encrypted over HTTPS, but this vulnerability is a particularly insidious one because it actually punishes sites for doing the right thing in the form of encrypting traffic.

Because of the particular memory read using this attack and the memory layout Yahoo's service ended up with, other users' decrypted login traffic would get sent back to malicious clients with high frequency.

[peterwwillis]

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.

[bri3d]

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.

[erichurkman]

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?

[bri3d]

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.

[peterwwillis]

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.

[voltagex_]

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