Epsilon Security Breach

Since my last post on the Epsilon Security Breach, the impact of the Epsilon security breach has gotten bigger. In fact, in an article posted on Yahoo news, a Reuters news writer stated:

In what could be one of the biggest such breaches in U.S. history, a diverse swath of companies that did business with Epsilon stepped forward over the weekend to warn customers some of their electronic information could have been exposed.

So the breach has grown since it was first announced last week. I wonder if this will get bigger  since the same article goes on to say:

“While we are cooperating with authorities and doing a thorough investigation, we cannot say anything else,” said Epsilon spokeswoman Jessica Simon. “We can’t confirm any impacted or non-impacted clients, or provide a list (of companies) at this point in time.”

The problem for Epsilon seems to keep growing. As developers, we need to remember this because the last thing any of us want is to the be developer responsible for letting the hackers in.

Security Has to Be Job #1

It’s been a busy week for security administrators. First, the Lizamoon attack last week. Then, data was stolen from Epsilon.

LizaMoon Attack

I first started reading about Lizamoon last Friday (4/1/2011). I was wondering if it was an April Fool’s joke but quickly discovered it was not. Depending upon what estimates you read, Lizamoon infected between 100,000 and more than 1,000,000 pages. In my opinion, the worst part of this attack is that it should have been prevented.

According to WebSense:

We were able to find more information about the SQL Injection itself (thanks Peter) and the command is par for the course when it comes to SQL Injections.

While the attackers did escape many of the characters to make it difficult to decipher what they were doing, SQL injection attacks are easy to prevent:

  1. Run your web application under an id with limited privileges.
  2. Use parameters in all SQL statements. This alone would have prevented this attack.

I found this attack disappointing. I remember reading about SQL injection attacks more than 5 years ago along with how to prevent them. How can we have come so far as an industry but still have so far yet to go?

Epsilon Attack

Sometime last week, Epsilon was attacked and had data stolen. I first heard about this when I received an email from BestBuy Reward Zone which included:

On March 31, we were informed by Epsilon, a company we use to send emails to our customers, that files containing the email addresses of some Best Buy customers were accessed without authorization.

We have been assured by Epsilon that the only information that may have been obtained was your email address and that the accessed files did not include any other information. A rigorous assessment by Epsilon determined that no other information is at risk. We are actively investigating to confirm this.

I received a similar email from Chase today. And, according to Engadget, more companies than these two had their data stolen:

A rigorous investigation has concluded that no other personal data was exposed, however it’s not just TiVo that’s affected — other big names, such as JPMorgan Chase, Citi, US Bank, Kroger, and Walgreens have also seen their users’ deets dished out to the unidentified intruder.

The good news is that only names and email addresses were stolen; there was no information stolen that would lead to monetary or identify theft.

But think about what this will do to Epsilon itself. They haven’t published how the hackers got in and stole the data and I could argue that they shouldn’t.

But hackers did break into their systems and steal data. They had to issue a press release stating as much. And, the impacted companies are blaming Epsilon for the security breach as they should. I wonder how much this will hurt Epsilon’s reputation and market share.

So, What’s Next?

The Lizamoon attack was caused by developers not accounting for SQL injection attacks in their code.

We don’t know what was the underlying cause of the Epsilon attack. From the press release and the apology emails being sent out, I think it’s safe to assume it was an exploit as opposed to a social engineering attack. That means it was probably either a developer-created security hole or operations falling behind on patching servers (or both).

So how do we prevent these types of attacks?

First, I think we as developers need to take more ownership of these types of problems and do more to prevent them. The problem with this is that we’ve heard this all before. And many of us do take ownership and work hard to insure our code doesn’t have any exploits. But a lot of us don’t.

Second, we need to educate our management so that security gets taken seriously. If we do find an exploit in existing code, fixing that exploit has to be a top priority. I bet that isn’t always the case. The problem is the risk and that is, I believe, the key to getting management to increase the priority of fixing exploits; by talking about what would happen if the exploit is found.

Third, we need better tools to help us determine if our websites are secure. Most of the tools that I’m aware of do code analysis and are looking for exploits within our code. That doesn’t help us in these cases because the exploits are in how our web site is working and not in how our code is working. Hopefully some good tools will come along shortly and will help us in this area.

>Passwords Becoming History?

So I’ve published before about passwords. Now this whole notion of passwords changing is going mainstream. Why do I say that? An article about passwords going away made it into Consumerist.  While I don’t think face scanning will necessarily be the security of the future, something will be. Personally, I think that a two-factor authentication method is the most likely option for web sites. For Windows, I’m not sure what it will be. I’m also not sure it matters because if somebody gets a hold of your machine, access is a pretty easy thing.

>Passwords & Security

>I’m surprised by how many sites and IT departments continue to force users to change their passwords every 30, 60, 90, 180 days. I find this practice annoying and wonder why everybody thinks this is a good idea. And why this is still considered a best practice.

There are now more opinions to back up my thoughts:

But, in spite of this, many IT systems still believe that changing your password every 90 days or so makes things more secure.

Don’t get me wrong, security is important. It needs to be job one in every application that stores anything about me and in every IT department. Protecting my data is very important to me and I don’t want to do business with a company that doesn’t believe security is important.

I do believe that you are more secure with a longer password. And I would rather have a long password than be forced to change my password every 90 days. The problem is that sites make the determination for me by forcing me to change my password. Since long passwords are harder to come up with and remember, I end up with shorter passwords because I take the path of least resistance.

Why am I so worried? In a 3year old post, Jeff Atwood, taking about a specific password cracking program in his Coding Horror blog says, “this attack covered 99.9% of all possible 14 character alphanumeric passwords in 11 minutes”. The problem is only getting worse. Some of the new cracker programs take advantage of the massive amount of processing power in the nVidia graphics processor chips cutting the time it takes to crack passwords by 60% or more.

Yet I’m still forced to change my password on some sites. So I go with shorter passwords because coming up with longer passwords is difficult and I don’t want to do that every 3 months. Why is it so hard to get IT people, including myself at times, to acknowledge how security risks have changed and to change our behaviors? And to change “best practices”?

>Secured Web Sites and Security Questions

>Why do sites keep adding those stupid security questions?  They don’t add security.  In fact, I believe security questions reduce the security of a site.  And I’m not the only one who thinks that. 

Yesterday, when I logged onto my ShareBuilder account, I was forced to pick 5 security questions and answers.  It was a struggle.  First, I had to work to figure out which five of the questions I could answer (sorry, but my father didn’t have a middle name).  The second struggle was figuring out, of the questions I could answer, which questions could I remember the answers to?  

So, for Sharebuilder now, if I forget my password, it forces me to remember five answers to five questions that I picked for a list they provided. I believe this will make it easier to hack my account.  And since this account manges some of MY money, I’m not happy about that.  I want to have to call them up and prove to them that I am me to get my password reset.  Again, this is happening because I forgot my password.  The hassle of making that call is my “punishment” for forgetting my password.  On the other hand, if I am calling because somebody trying to hack my account suspended it, I’d be very happy I had to call since that might be the only way the hacking can be stopped.  

ShareBuilder did add some other login security measures too.  Now, they ask for your user id and then display a picture and a phrase to me when they request my password.  That also means I enter my id and they validate it before I’m asked for my password.  So, if I’m trying to hack accounts, I get immediate feedback on whether or not a user name I entered is valid.  Is that really more secure?  Or does it just feel more secure?  

I really do believe these five questions make my ShareBuilder account less secure.  Maybe it is time to move my money.