3 ms·
you are underestimating the severity of the bug. The bug leaks server memory - in which case unencrypted passwords are being sent to the server by the user's br
by barkingcat 13y ago
you are underestimating the severity of the bug. The bug leaks server memory - in which case unencrypted passwords are being sent to the server by the user's browser in order to be hashed to be compared to the hashed versions in storage.
Normally this is protected by tls, but as you can see, for servers that suffer from this hole, it's as good as naught.
Note that this occurs for "any" connections hitting the vulnerable server, meaning that the patient attacker can just run this in a script and scoop up passwords, credit card #'s, form information POST'ed in by all users of the web service all day long until the hole is closed. and even then there's a good chance that the private keys were already exposed, in which case the attacker can now masquerade as the server.
- tvilot 13y agoI don't think I have come across a more succinct explanation of the problem. Thank you.
- klapinat0r 13y agoThis is why I always make sure to GC, delete or NULL input variables (you must include the request; body et al.) after encrypt/hash/<mechanism>. I basically take the stanze that I want as little to do with your real password as possible.
- mdda 13y agoPerhaps you should over-write them with garbage before doing this. Simply deallocating them (or assigning them to new objects) could leave them hanging around in memory until something else overwrites the same memory space.