41–50 of 70 posts
A malicious server can also read the memory of a client using the same heartbleed vulnerability. So the -NSA-mafia can go get the private key from a vulnerable server, MitM its clients, and attack those clients too. Nasty stuff. And in the last day, even those agencies that didn't know about the vulnerability beforehand have likely spidered the entire web scraping everyone's keys just-in-case.
Recovery process for this seems like it would be: - All affected sites need need to update OpenSSL, reissue certs, tell users to update their passwords. - All users need to reset their passwords, using a unique password for each site if possible. If they can't feasibly use unique passwords for each site, they need to make sure they don't use their new password on sites that aren't fixed yet. That's pretty crazy, and…
This is scary: # ./hb-test.py mail.yahoo.com |grep -A3 -B3 pass
What's potentially scarier than plaintext passwords leaking out is that key material leaks as well. 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 int…
For SSH it's common to use private keys to communicate securely with servers using public key cryptography. This is convenient and protects against key loggers. What are the possibilities of using public key cryptography in the browser? For example, I upload my public key to some website, create an account which is locked to my private key. I get the convenience of not having to log in manually and some extra safety.
I believe what you're describing is encompassed by SSL client certificates. They're supported, but roughly nobody uses them for some reason.
Earlier quoted context omitted.
What's potentially scarier than plaintext passwords leaking out is that key material leaks as well. 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 int…
This isn't my area, but why would Yahoo even have plaintext passwords in the first place? Shouldn't they only have hashes?
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.
Client web browsers are not affected because:
Firefox uses NSS on all platforms.
Chrome uses NSS on Linux or platform libraries for SSL or uses NSS on all platforms for SSL, and then uses the system libraries for other cryptographic operations and certificate validation.
Platform-specific browsers (IE, Safari) likely use their platform's SSL code.
Almost every other mainstream browser is a derivative of one of the four mentioned so far.
Edit: As another commenter pointed out, client-side consumers of the OpenSSL library are likely affected as well. That means web spiders and server-side code that uses web APIs are likely affected. That may or may not be concerning, depending on the networks that traffic travels over and the method of authentication.
Earlier quoted context omitted.
What's potentially scarier than plaintext passwords leaking out is that key material leaks as well. 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 int…
This isn't my area, but why would Yahoo even have plaintext passwords in the first place? Shouldn't they only have hashes?
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.
Earlier quoted context omitted.
What's potentially scarier than plaintext passwords leaking out is that key material leaks as well. 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 int…
This isn't my area, but why would Yahoo even have plaintext passwords in the first place? Shouldn't they only have hashes?
Earlier quoted context omitted.
This isn't my area, but why would Yahoo even have plaintext passwords in the first place? Shouldn't they only have hashes?
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 HT…
There seems to be some confusion about the vulnerability on the client side, which I think should be clarified. The Heartbleed vulnerability seems to only affect OpenSSL clients and servers. The buffer overrun is only known to be in OpenSSL, so other SSL clients should be unaffected. Client web browsers are not affected because: Firefox uses NSS on all platforms. Chrome uses NSS on Linux or platform libraries for SSL…