LinkedIn’s Sloppy Security Should be a Lesson to All

Not all security breaches are created equal. Take last week’s LinkedIn fiasco as an example. As it turns out, LinkedIn didn’t even take rudimentary steps security experts say are Security 101 for data protection.

LinkedIn reportedly didn't take its security measures quite far enough, making a data breach much worse, as passwords leaked.

That made a bad situation for LinkedIn, downright horrible because while the breach can happen to anyone, what happened once the hackers got inside the system was reportedly preventable.

And this should be lesson for every IT Pro out there. Do whatever you can to protect your data. You might not keep hackers from passing inside your firewall. As we’ve learned, that’s just way too easy to do these days, but do whatever is considered standard best practices to protect the data once the hackers get inside.

As I wrote in a post last week, Cloudflare Attack Proves Hackers are Relentless, hackers are surprisingly creative when it comes to breaking through your security. In the Cloudflare case, they used four unrelated vulnerabilities to get inside the system. When hackers are that, well, relentless, it’s hard to guard against attacks.

But news stories emerged late last week with details about the LinkedIn issue. Surely, hackers found their way inside LinkedIn’s defenses, and that was problem number one, but the bigger problem was once inside, they could grab fistfuls of passwords because as the Storm Blog reported, LinkedIn did only half of what they should have to protect the passwords.

As the Storm Blog post explained, there are two levels of password security. One is called Hashing and the other Salting. Hashing places the password inside a protective hastag, but it’s not enough because if you just hash, you can still read the password. That’s why you also have to salt, which adds extra information that makes it more difficult to extract the password.

LinkedIn did the former, but not the latter and that was a big mistake on its part.

From an individual standpoint, it meant if you share passwords across sites, it’s time to change that universal password. Matt Heuser wrote a post on TechTarget with some smart password writing rules.

But we know that individuals are the weakest link in your security chain. You probably don’t want to leave it up to them. If you’re looking to secure user data, you need to take every step you can to ensure that the data is safe as possible.

The New York Times reported that within a day of the breach there were already phishing attacks based on the newly found information.

Meanwhile LinkedIn refused to fess up and take full responsibility for the action saying it wasn’t as bad as reported. Wrong way to deal with the issue.

Breaches are going to happen as sure as the sun will shine, but if you’re a company like LinkedIn, you need to be taking the necessary steps to ensure the data is as safe as possible. If you fail to do this, expect to be called to task when a major breach occurs and your user data is scattered to the winds. And if you have an issue, for goodness sakes, be open and honest with your user base about what happened. Don’t deflect and deny or it will only make it worse.

5 Comments

  1. chort says:

    A few factual errors:
    1. Cryptographic hashes are not “hashtags.” Hashtags are so named because they start with ‘#’, which is known as a hash symbol. Cryptographic hashes are a one-way function with a fixed length of output for a variable length of input, virtually guaranteeing that two inputs cannot create the same output.

    2. It’s not possible to read passwords out of hashes (hashes are, by design, not reversible functions). It is possible to generate tens of thousands, to billions of hashes per second and attempt to “collide” the output of the hash with existing hashes (that were stolen). If a stolen hash matches a generated hash, that means the attacker can supply the same plaintext to the authentication systems and it will be accepted as a match.

    3. Salting merely changes the starting point of a hashing algorithm, so the same input and same hash function won’t generate the same output every time. This is only effective to protect against an attacker generating one hash and comparing it to every hash they’ve stolen. It doesn’t protect at all against and attacker trying to collide a single hash.

    4. LinkedIn’s REAL mistake was using a simple cryptographic hash (designed only to guarantee message integrity) to store passwords. Cryptographic hash functions are designed to be very fast, so message integrity can be verified very quickly. Passwords, on the other hand, need to be stored with very SLOW algorithms, because they’re defending against an attacker who’s trying to guess the original input (rather than trying to modify it, in the case of message integrity).

    5. One of the reasons why companies keep getting this wrong over and over is due to a lack of clear information. This article does not help.

    • Ron Miller says:

      Thanks for the clarification. I was obviously way out of my league on this one and I appreciate you providing us with more accurate information.

      Ron

  2. droope says:

    Hey there. I think you might be overreacting a bit.

    Not salting your hashes is not a bad practice per se, some people don’t even agree a salt enhances security.

    • Ron Miller says:

      Droope
      Great interview. Thanks for sharing.

      Ron

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>