Livingsocial got breached. You need to change your password, if you have a Livingsocial account.
There are two questions worth asking: How do you protect yourself, and how does this happen?
Easy question first: Use a long, complex password. The Federal Reserve password database hasn’t been cracked yet, because those passwords are all 12 characters long, with a minimum of two uppercase and two lowercase letters, two numbers, and two symbols.
No matter the online service, no matter how sloppy their security is–unless they’re storing the passwords in plaintext, in which case they’ll be ripe for a lawsuit–complex passwords are much harder to crack than simple passwords like “password1.” Here’s a sufficient–not great, but sufficient–formula.
So, how does it happen? Generally speaking, by getting some malware in the front door somehow, then pivoting to a server with interesting data on it. Sending an infected resume to HR would be one way to do it. Has your organization hardened the HR department’s computers? It’s something you need to think about doing.
“Pivoting” is security-speak for looking around on the network for something interesting to jump off to. It’s generally much harder to get in the network than it is to jump around afterward. I’ll save the specifics for my job interviews, but the most vigilant shop I ever worked in was still usually a month behind on its Microsoft patches. When I’m talking to other security guys and they start talking about their organizations, I want to stick my fingers in my ears and say, “I don’t want to hear that!” I won’t repeat what I’ve heard, because it shouldn’t be known.
There are ways to stay up to date on your Microsoft patches, but it takes careful planning, good deployment software, determined security-minded sysadmins at the controls, and buy-in from management, at the very least. The more I think about it, the more I think I was severely underpaid when patch administration was my primary responsibility.
What if the servers are in a DMZ, you ask? Hop around until you find a developer’s computer. At one job I worked, an external organization (they had permission) once got into our DMZ by doing exactly that. They found a developer, put a keylogger on his computer, watched where he went, and suddenly they had admin rights on the servers in the DMZ. Then they sent screenshots up the chain of command, and then I had 64 hours to make sure they didn’t get back in again when they tried on Monday morning. Yes, I found out on Friday at 4 that I had until Monday at 8 to make sure they couldn’t get in, or I would be looking for a job.
They didn’t get in. It made for a long weekend, and I had to cancel all my plans for that weekend and so did a bunch of other people who helped me get that network re-secured, but we all got to keep our jobs.
Frankly, I don’t care who you are, I wouldn’t be surprised to hear your password database was stolen. Really. And the breaches can happen without you knowing it.
The way you generally find out is when a bunch of your password hashes show up on an underground forum somewhere with a request to crack them, and then a bunch of the passwords contain your organization’s name. Or, worse yet, someone else sees it, and you find out the same way and at the same time as the rest of the world does–through the newspapers.
Since preventing the password database from getting stolen is impractical, one has to assume it will get stolen, and then take two compensating measures.
End users need to use stronger passwords.
Companies need to move away from using MD5 or SHA for storing password hashes and toward stronger, slower methods such as bcrypt. Slower is key. MD5 and SHA were sufficient for the Pentium 4 era, but in the Core i7 era, we have to make the job harder.
Most users are going to resist longer passwords and more onerous requirements–I know from experience–so it behooves companies to build bcrypt into their e-commerce sites to compensate. The whole idea for 8-character passwords was that it would take a year to guess them, and we would change them more frequently than that. But as technology marched on, we didn’t lengthen passwords to compensate, and now people are used to that length. Good security is largely about compensations; that’s a compensation we can make on the developer side.