This reminds me that a certain large site includes my username and password in its periodical mailings (PlentyOffish.com). This means they don't use a one-way hash for the passwords.
This is negligence; plain and simple. Users have a right to expect web service providers to keep their private information secure with basic industry standards. Someone should sue them and set a precedent.
Ehh... SQL injections are not on the same order of seriousness as storing passwords in plaintext, IMHO.
The average web service has a complexity far greater than any college course project. SQL injections can be mitigated using the correct tools and methodology, but things like this (and buffer overflows) will continue to exist. Such is the nature of things.
There's "oh man, this one variable isn't sanitized", which is a bad, but understandable mistake.
Then there's "oh man, we don't encrypt our passwords AT ALL", which really belongs in the realm of mistakes made by 15 year-olds.
No seriously, the last time I made that mistake was when I was 15.
And some of those companies get caught out and lose a lot of money for it. I'd rather retake the failed class. The real world is harsher than academia.
But if the company spent its time solving every theoretical security problem, it would have never had a product to make money with in the first place. It is a balance, and "zero tolerance" is silly.
(So is not using a modern database abstraction library. Even PHP has them these days!)
This is why the Rails Tutorial book (http://www.railstutorial.org/book) will be teaching authentication using salted, hashed passwords. Watch for Chapter 5, due out some time around New Year---and please forward it on to the nice fellows at RockYou. (Maybe, while we're at it, we can get them to ditch PHP for Rails.)
This is more valuable than spam - you have passwords, which for most people are practically global. You also have their email addresses, which nowadays are basically the same thing as login.
You just opened the door to everything about these users.