>LivingSocial engineers should be applauded for adding cryptographic salt<p>Should they? Should they really? Should we also give them a cookie for properly dressing themselves in the morning?<p>Uniquely salting and hashing passwords is the bare minimum for acceptable security practices. It is not a sign of expertise, but of competence.
I don't get why they used SHA-1. I mean, LivingSocial has been sending people to speak and attend a lot of developer conferences. They hire a lot of bright people. Did none of the Rails devs raise an alert of like "Uhh hey guys, why don't we use Rails-community standard bcrypt?".<p>I suppose it could be corporate bureaucracy or something, but it seems weird that a company with at least 30+ developers (based on public members on the github org) no one would point out that this is a Bad Idea.
Hearing about all these recent hacks (LinkedIn, RubyGems, LivingSocial) really makes me nervous and wonder how I can avoid hacks. Are there any details on how these systems were hacked in the first place, so that the rest of us can learn from the lessons? I already use as many security good practices as I can (bcrypt, processes and apps running under different user accounts and database accounts, read-only accounts, principle of least privilege, firewall, fail2ban, key-only SSH logins, file modification monitoring, forwarding logs to a log host, etc) but I can't shake off the feeling that I may be forgetting something.
I wonder why password tables are readable at all. An application only needs to call a stored procedure that compares the computed hash value against the stored. This stored procedure needs the rights to read the data. No application, no administrator should to be able to read that data.
Are tech companies that store a fair amount of personally identifying information on millions of people ever subject to security audits? Not saying it would help, but it seems like as attacks get more prevalent and old security practices become obsolete that users might be able sue companies for negligence by not using optimal data encryption. Of course the tech company would counter sue for stupid passwords. And even if they want to restrict users from dictionary passwords with symbol replacements, hey, it's patented.
One way they could have upgraded their database to make it more secure: <a href="http://blog.jgc.org/2012/06/one-way-to-fix-your-rubbish-password.html" rel="nofollow">http://blog.jgc.org/2012/06/one-way-to-fix-your-rubbish-pass...</a>
Everyone should be salting and hashing correctly - it's trivially easy to implement and the cost is trivial. However, once the user database is stolen in its entirety, there are other factors that become as important:<p>- Did the user use a common passwords? If they did, then it will quick to brute-force.<p>- Did the user reuse the same credentials on other sites? If they did then the value of recovering the password becomes worth plowing through well-salted scrypt.<p>The real problem is that far too many people use the same credentials for LivingSocial and their Gmail.