LinkedIn hack – the reality
I expect readers have heard about the LinkedIn hack, either in the news, or via an email from LinkedIn with password reset instructions if your account appeared on the leaked list.
LinkedIn have now also added salt to their hash, so along with using SHA-1, which is a mathematical algorithm that turns a string of text into a unique string of indecipherable characters, they’ve added a further string, so that a hacker needs to know this string in order for them to work out your password in addition to calculating their own SHA-1 hash.
Given that LinkedIn have plugged the hole by resetting compromised account passwords and implementing salt, it does beg the question as to what has actually happened since the leak of the hashed passwords and now. Speculative reports say the leak happened many months ago, which makes perfect sense. A hacker with this information certainly wouldn’t publish it day one, they would work on it, exploit it to their full advantage and throw the leftovers to script kiddies just for lulz.
So what benefit is there for someone knowing your LinkedIn password? Well, firstly, LinkedIn doesn’t tell you when you last logged on. If your account had been used, you’ve probably no idea. Hackers could have exported all of your personal connections without you knowing, but they don’t appear to have done anything “malicious” or defaced accounts. What I suspect they have gained is a huge list of usernames, email addresses and passwords. Now password re-use is a big issue. LinkedIn do not appear to have pro-actively warned users to make sure their LinkedIn password is not used on other sites (unless you read their blog and understand it – . It is very common for users to use the same email address and username aross many sites (Facebook, LinkedIn, Twitter, work email…), and whilst LinkedIn may have disabled potentially affected accounts, it would be nice to see Facebook push out a warning about password re-use as they are very much a prime target for it.
Going back to what I said earlier about salting hashes. This does add extra security, but even with salt, if a cracker has the hashed value and the plain text that goes with it, then ultimately the hash and salt can be identified, and given the huge potential of 6.5 million records, crackers would certainly put the resources and time in to do this. This can be combatted by using a long salt and using a unique salt for every password. I just hope LinkedIn have done this.
What can we learn from this?
Given the very real threat of a $10bn IPO company being breached and not having the time, money, resource or application security know how to secure passwords properly, then what chance does Joe Public Ltd. have?
Well, if you are a SME, your systems are likely to be simple, you’re fairly obscure and unlikely to be a target, so this might buy you time.
If you do run a web application with usernames/passwords, then never write the password to disk in plain text, always use a long, unique salt for each password you do store and do have the absolute confidence that even if the password hash does fall into enemy hands, they cannot reverse it with rainbow tables!
This isn’t the first time that application security hasn’t been properly joined up with an entity’s information security program, and will not be the last.