> Playing devil's advocate, but this still prevents lots of web-based attacks. Provided you store the encryption key on the filesystem, or in memory and the encrypted passwords in the database usually you'll get access to only one part.
Why would you assume this? It's entirely possible that a compromise will allow file system access, which will give the DB and the key. As for memory storage, you've got to have the key somewhere so that the machine can restore itself after a reboot. An in-memory-only key isn't a very practical solution. It's also entirely possible that you memory-only key will find its way to the swap file, again vulnerable if FS access is gained.
> But it gets better! If you have access to the encrypted passwords, but not the key, then they're safer than hashes, since the attacker cannot try to bruteforce them (he could try bruteforcing a very very long encryption key of course...)
This isn't necessarily true. Hashes are not intrinsically easier to break than encryption. Some hashes (such as bcrypt) are based on an encryption anyway.
you've got to have the key somewhere so that the machine can restore itself after a reboot
In many very secure systems, this "somewhere" is in the brains/completely secondary data stores of a group of admins who enter that key when a reboot occus.
I think it's unlikely enough to ignore it here, though. Is someone who's willing to send an email in plaintext going to do this? Why bother when simply hashing would do the job more effectively?
I agree it's possible for high security situations where passwords need reversibility, though. e.g. I wouldn't be surprised if Intuit used a system like this when they store passwords for external services. (They should still be hashing users' primary passwords, though.)
I should have clarified that I was referring to accessing the swap as root. This also requires another privilege escalation, and is a separate issue I probably should have left out.
Why would you assume this? It's entirely possible that a compromise will allow file system access, which will give the DB and the key. As for memory storage, you've got to have the key somewhere so that the machine can restore itself after a reboot. An in-memory-only key isn't a very practical solution. It's also entirely possible that you memory-only key will find its way to the swap file, again vulnerable if FS access is gained.
> But it gets better! If you have access to the encrypted passwords, but not the key, then they're safer than hashes, since the attacker cannot try to bruteforce them (he could try bruteforcing a very very long encryption key of course...)
This isn't necessarily true. Hashes are not intrinsically easier to break than encryption. Some hashes (such as bcrypt) are based on an encryption anyway.