Ambush Commander wrote:I'm starting to think that not only should passwords be hashed, so should any sort of sensitive data that doesn't need to be regurgitated.
Be careful that carrying a hammer makes everything look like a nail. There are few other pieces of data that you need to verify, but not access/display. As a result, hashing is rarely useful for webapps beyond data verification and password hashing.
Thats not to say its NEVER useful beyond those, but, its rare.
Ambush Commander wrote:Just an interesting thing to note: whenever the password is sent to the server to, say, login, the server knows about the password. While this somewhat dampens security, it also makes upgrading hashes possible.

See AuthTools for more details.
Not neccesarily. Depending on how you implement it, the server may only receive the hashed version. As you mention, you can in fact make a tradeoff in security and send it plaintext, but then you are solving one problem (encrypted storage) while ignoring another (plaintext in transit).
AGISB wrote:Thats an American problem and not a security one. The people only care for an easy buck and the US law system provides them with the means. Besides that people don't sue sites that didn't save their password encrypted and the same password was used to get into other sites where the danger was done.
You both misunderstood my meaning, and made a wrong conclusion.
I provided the link to disprove your earlier statement that "Users don't care". They do care, and they care enough to take their business elsewhere AND file lawsuits to show just how important it is. Thats not an American problem - thats a
business problem. If you choose to ignore security issues, it will impact your bottom line. Thats why several security professionals in this thread are telling you that in the real world, choosing not to hash a password isn't a choice at all, let alone a valid tradeoff.
Further, people do sue for damage done beyond the site compromise itself. Identity Theft is a huge and growing field in the legal community, and compensatory damages have been awarded in numerous cases where litigants have been able to prove negligence. Not encrypting passwords, despite having an easy ability to do so, is absolutely negligent handling of data.
AGISB wrote:It takes less then a couple of hours to create a new rainbow table using a dictionary list or some other lists including a known salt. This is in now way comparable to brute force.
You do not understand the meaning of Brute Force, and Rainbow tables.
Rainbow tables are simply stored output from a brute force attempt. Limiting that brute force attempt to dictionary attacks, is still a brute force attempt - it just has a smaller range of targets.
Further, building a rainbow table, with a salt, for all possible *dictionary* words (we're going to assume no users have anything but that) takes far longer than a lookup. It can take days for even 8 characters.
Now factor in that *each* user could have a unique salt, and its suddenly days for *each* user. That *is* a substantial improvement, and yes,
it is comparable to a brute force attempt.
AGISB wrote:The other thing is that you always must have a backup for transmitting unhashed passwords or you need to require all users to have jaascript on which will smurf many off.
I guess you don't use the web much.
Plenty of sites do not do so, and keep large numbers of users - even ones with javascript off. PHPBB, for example, simply assigns you a new temporary password, which it mails to you, and then allows you to reset it to one of your choosing. Ebay has a similar system, as does Yahoo. Gmail sends to your cellphone (how cool!?), and I've seen plenty of other systems.
The point is, there is no reason today to store unhashed passwords. You don't have to require users to have javascript on, you don't have to ruin your "recover password" system, you don't even have to give up testing the strength of their passwords. There is a way to solve every issue you've brought up, they've been used on dozens of (very) successful sites, and the sky isn't falling for them - but it is falling for companies taking
stupid risks with people's data. Please stop arguing that doing so is okay.
AGISB wrote:Again I am not stating you should not use hashing. My point is that the security enhancement is not as great as many peole think.
Actually, on multiple posts, you've argued that you don't need to, that there is little benefit in doing so, and that not doing so is reasonable. None of those are accurate, and they are all supporting arguments that lead people to not use MD5. Thats irresponsible, and its wrong. We've clearly answered every issue you've brought up that you claim justifies not hashing passwords.
AGISB wrote:But sometimes you have to go with a little less security, even more so if the customer requested functions that need it that way. That customer doesn't care about if it is less secure he just wants what he wants.
1. There are no functions that "need it that way". Every issue you've brought up can be addressed while still hashing passwords.
2. The customer does in fact care deeply about not being sued, not losing customers, and not looking incompetent because they ignored a critical need for protecting customer information.
There really isn't anything left to discuss. Hashing passwords is in every way a substantial improvement in security, and depending on your specific needs, can be implemented without any impact on functionality. Its best practice, it has low overhead, and there is no valid justification for not doing so.