Does that mean that if/when an attacker uses a SQL injection vulnerability to obtain the contents of your database, will he then have a password equivalent that allows him to login as the users?
Will it enable him to mount brute-force attacks against the users' plaintext passwords?
> Does that mean that if/when an attacker uses a SQL injection vulnerability to obtain the contents of your database,
More pedantry: if you have a decent RDBMS like Postgres and connect to the DB always as some user A (using a Pg function with SECURITY DEFINER defined by a superuser to compare passwords with a delay, hashed or not) and use column-level permissions that disallow access to the password (or hash) column to non-superusers, they can sql inject all they want (any attempt to dump/select the password column will fail, unless they also manage to reconnect to the database as superuser).
I like RDBMS security (and I think it needs to be employed more frequently), but there's still no valid reason to ever store a plaintext (or plaintext-equivalent) password. Storing something toxic in a "safe" way doesn't make what's being stored any less toxic. The effort to create and maintain a "secure" one-off credential storage system seems like a waste given the availability of well-tested, accepted methods of credential hashing and storage.
> The effort to create and maintain a "secure" one-off credential storage system seems like a waste given the availability of well-tested, accepted methods of credential hashing and storage.
I disagree, because what seems safe today might be unsafe tomorrow or in 10 years. Does anyone still remember Unix versions without a shadow passwd file? I do ... But why do we use that even today when modern Linux installations use SHA variants by default?
Because 50% of typical users will choose one of the top 10,000 most-common passwords and no practical amount of work factor will save them if the hashes become known.
Consequently, DB column permissions are also worth it because they hide the hashes, while such people are not protected at all by current hashing schemes.
The Postgres function written to compare passwords/hashes can also limit the number of checks per time unit to prevent brute-forcing.
Will it enable him to mount brute-force attacks against the users' plaintext passwords?