> But it doesn't have to be in memory, or otherwise stored, anywhere near the bulk account data. If the encrypted password is transferred up the application lay

> But it doesn't have to be in memory, or otherwise stored, anywhere near the bulk account data. If the encrypted password is transferred up the application layers to another physical resource that knows the key, and the passwords (encoded and not) or securely wiped from memory immediately after the comparison then this offers some useful protection over plain storage. An attacker would need to compromise both resources (the data store and the key holder) in order to get hold of credentials. For this to be meaningful the security of those resources and the communication between them must be very carefully designed and implemented, but it is wrong to say symmetric encryption is necessarily no better than credentials stored in plain form. If the system can automatically verify a password, i.e. decrypt it, then an attacker can leverage that. You could design a system very carefully that might be invulnerable to memory injection attacks, might not be on boxes that have root escalation vulnerabilities, and which might be using a secure hardware security module--but why? You don't need to. Just use a one-way function. > As per my other post (https://news.ycombinator.com/item?id=6120089 https://news.ycombinator.com/item?id=6120089) the reason this is done is to permit partial password checking which is used to reduce the chance of successful reply attacks. Just add a PIN or something else that doesn't give you full access to the account. No reason whatsoever to store passwords people use on many other sites in what is, on 99.9999% of systems, equivalent to plain text.