Because you are going to lose your entire database, and everyone's password along with it, to the first SQL Injection vulnerability you miss in your application.
I was referring to a careful implementation by competent people. An organisation opting to store in plaintext would have to have special precautions so that could never happen.
The implementation I have knowledge of is separate from the "main" DB, accessible only over an internal REST interface and heavily secured. There is no way a simple attack or compromisation of a web server could make it spit out the kind of "jackpot!" list you're talking about. The infrastructure is layered like a frickin' matryoshka doll and frankly you would have more luck just robbing a bank.
So it is possible to do well, with due care and attention and a competent paranoid admin. Not advisable or desirable for a "normal" system, I agree completely.
>> An organisation opting to store in plaintext would have to have special precautions so that could never happen.
What everyone is trying to say is there are no foolproof measures to securing data. Everyone who thinks their method is safe becomes the case study for the next generation.
Also, social engineering and disgruntled employees trump internal software architecture everytime.
My point is that although password hashing is a very wise practise, there are situations in which the plaintext is necessary, and with careful design a plaintext password store can be made no weaker in security than the rest of the system.
This seems to me to be common sense and I have no idea why it's so controversial.
Well then, in your parallel universe, by all means store plaintext passwords. I'll go on busting up the real apps, and recommending they don't tempt fate by storing passwords.
I recommend that too but sometimes it is unavoidable. When, not if, but when you come across that necessity in your encounters with "real apps", I hope you rightfully feel like a bit of a douche for writing the above.
