[gmazzola]

From a theoretical security perspective, it's a terrible idea to store passwords in plaintext, but again there's a difference between theory and practice as you've stated. If your auditing can reduce/eliminate unauthorized out-of-band database access, then in practice storing plaintext passwords isn't a huge problem.

However, there's another practical aspect to consider: the password security of users. A perfect example from a month ago is a Christian dating website called Singles.org. The 4chan crowd discovered that if you replaced your user ID on the "profile edit" page with another user ID, you could edit another person's profile. The page also helpfully displayed the registered e-mail address and password, in plaintext.

Now, this is terrible programming on multiple levels, so you might want to discount my anecdote, but the attack vector isn't my main point.

The 4chan crowd, ravenous beasts that they were, attempted to use the Singles.org password to log into the victim's e-mail account. And their Facebook account. And their PayPal account. You can imagine the chaos they caused.

The user base had terrible password security, so easily around 20% of the accounts had the same password across multiple websites. I don't think it's an uncommon statistic: sadly, even I as a security-conscious person have used the same password more than once.

Our efforts should be to secure an application against all attack vectors, but hashing passwords is a veritable last defense to prevent an attack from spreading on to other websites.

Regardless of how an application is exploited, it's a safe assumption that the users' poor password security could spread the attack further. I would thus claim that plaintext passwords be at least a "medium" security issue.

[philh]

Being able to get access to plaintext passwords is obviously a terrible security flaw. But would it be much less bad if an attacker got access to a lot of hashed passwords? A dictionary attack will get you many of the plaintexts in a reasonable timespan. Possibly users with dictionary words as passwords are also more likely to share them across sites; certainly the intersection is nonempty.

People with strong passwords might remain safe, but not necessarily. A bruteforce is much more worthwhile when you're trying to crack thousands of passwords at a time. If there's no salting and the hash algorithm is widely used, you may not even need to worry about getting exactly the original rather than something which happens to collide with it.

Obviously hashing is still better than no hashing, especially since there will be cases where only a few passwords are leaked. But if a database containing passwords is stolen, it may be reasonable to assume all those passwords are compromised, even if they were hashed.

[gmazzola]

If the password hashing scheme is secure (bcrypt, as tptacek repeatedly recommends) dictionary attacks become non-trivial and slow. It's still possible to brute force the database, of course, but the time required makes the attack less profitable.

I would thus argue that a secure hashing schema is significantly better. This is assuming the programmer uses bcrypt in the first place, which is a questionable assumption: even popular projects like phpBB use MD5 for password hashing. (The fools.)

If MD5 is used then I would wholeheartedly agree with you: I've used http://milw0rm.com 's MD5 hash breaking service plenty of times to know why I shouldn't use that algorithm in my own code. (One of my old passwords is in the database, but I'm not telling you which one.)