# ./hb-test.py mail.yahoo.com |grep -A3 -B3 pass
64k of random memory is bad, 64k of OpenSSL's state is worse.
Also, why haven't Yahoo taken down their login service yet? I really don't see how leaving your users' passwords leaking in plaintext is ever better than downtime. Someone had to have made that call, and I really don't think it was the right one. Will be interesting to see how the media treats this over the next few days.
EDIT: Looks like Yahoo is finally fixed. Wonder how many accounts were compromised in the interim, and if their cert and private key were compromised as well. Does not look like they've re-issued yet.
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.
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.
Thus, the key exchange doesn't need to be exposed for heartbleed to have a good potential to leak TOTP/2FA secrets.
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.
1.) Client sends Plain text user/pass over SSL -> 2.) Server reads that info to memory -> 3.) Server hashes password and tests hash -> 4.) Server discards plaintext memory.
Whats happening here with heartbleed, is you are reading the RAM of the server, so before Yahoo even has the chance to hash the password, this exploit allows you to read the password.
Remember, even though Yahoo may only store the hashes in the database, your password (for any service) is still being sent effectively as cleartext.
I'd like to start changing passwords, but it doesn't do much good until things are fixed.