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.
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!)
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.
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.
Although they shouldn't be emailing you your username and password, there are plenty of 2-way encryption schemes out there. (AES128, blowfish,...)...so it might not be sitting in the db in plaintext.
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.
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.)
23 comments
[ 44.6 ms ] story [ 82.4 ms ] threadhttp://en.wikipedia.org/wiki/Product_liability
Normally I'm not so hasty to call for head-chopping and head-rolling family fun, but I would think this is entirely called for.
My final project in class gets and instant 0/100 (40% of the grade) if SQL injection was possible...
(So is not using a modern database abstraction library. Even PHP has them these days!)
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.
SQL Injection is very very common. I've worked on sites that never sanitize anything.
Totally guessing I'm thinking $0.50/1000 to $5/1000 for: $16,000 - $160,000. But I don't even know if I'm in the right ballpark.
I also assume you can resell these many times, so it could conceivably be worth hundreds of thousands.
You just opened the door to everything about these users.