As you may have read in the news lately, Sony is in a lot of hot water after it's network was hacked.
So far, Sony has admitted that personal account details of 77 million users were stolen. This would make it the greatest data theft in history.
Sony is still investigating whether credit card information were stolen but apparently, user records containing information such as name, date of birth, email and passwords were.
Whilst PS3 users seem concerned about their network being down for a week - the thing I was more fixated on was how the passwords could possibly be stolen. Well, apparently, Sony never bothered to encrypt them!
Now, I'm by no means a IT security expert here but I've worked on enough IT systems and projects to understand that ** **
YOU NEVER STORE USER PASSWORDS IN PLAINTEXT!
Never, ever, ever!
It doesn't matter how small or insignificant your site is. In fact, it always used to bug me whenever I registered a user account from a new site or forgotten my password, and I received an email with my password in it.
I would be quick to either deregister myself or at the very least, change the password and hope that my normal password wasn't sitting in some audit table somewhere.
Because the fact they could retrieve my password meant that they had it.
And it happens more than you think - not just on small sites, I've been surprised by a few relatively big players. I remember Prometric (they also have a really crap website) - the company that manages Microsoft certification exams emailed me my password. This is a company that makes its living testing and certificating IT professionals!
Frankly, I think somebody should set up a Name and Shame list of any websites that store passwords in plain text.
But for a company like Sony - a huge multinational, a company worth billions of dollars, a company that made the PS3 which for a long while, was considered the first unhackable console (until it was) , it's just utterly unbelievable that they did not follow such basic and rudimentary security measures.
The reason you don't store passwords in the database is that most users, lacking an eidetic memory tend to re-use the same passwords over and over again. If they have their password stolen from your site, its likely the hackers will have access to other accounts they own.
The other reason is that all staff members with production db access can see it. It takes one disgruntled employee.
You should never store passwords in plain text cause you don't want the liability.
INSTEAD, STORE A HASH VALUE GENERATED BY THE PASSWORD.
Hashingis the process of running some plaintext (password) into an algorithm (eg. MD5) which returns a "hash" - basically an encrypted string value. It's a one way street - you can convert the plaintext to a hash, but you cannot use a hash to retrieve the original text. You compare the hash to verify when someone tries to log on.
The fact is, implementing hashing is not even that hard. There's really no mathematical or cryptographic knowledge required. All major programming frameworks have class libraries of the hashing functions pre-installed. All you have to do is call the function.
That's the absolute minimum you would expect of any website.
Although these days, simply hashing is probably not enough as it will not protect you from Rainbow attacks. Now rainbow attacks sound cute and kind of a bit queer, but essentially, a rainbow attack uses a rainbow table - which is a prepopulated table containing hash codes for every possible password combination - to quickly look up your password.
With the super fast processors and distributed computing options we have today, you would be surprised how entirely possible it is to get the hash for every combination of letters and numbers that a password could have. There are several freely available on the net. This page nicely illustrates how much time it would take based on the complexity and length of the password.
IN ORDER TO COMBAT RAINBOW ATTACKS, YOU MUST ADD SALT.
In layman's terms, this is the process of messing with the plaintext a bit before you hash it to order to ensure it is unique and will not appear in any pre-populated rainbow table.
To illustrate, a hash without salt looks like this
cipher = hash(plaintext)
After salt, it should look like this
cipher = salt + hash(salt + plaintext)
The salt is typically a GUID as it guarantees uniqueness. You don't need to hide the salt - in fact, the salt is used when verifying if the user has entered the right user name by taking the value of the salt into account when comparing the hash values.
A hacker cannot use a rainbow attack on you because the salt makes the plaintext unique. They will need to re-generate their rainbow tables again using your salt prefixed which will take as much time as a brute force attack.
No encryption is unbreakable of course, it's all just a matter of how much time a hacker has to spend before he breaks it so there are additional measures such as adding multiple iterations of hashing to provide additional protection which I may discuss in another post.
The point is, hashing and salting - these are not complicated concepts and they're really not that hard to implement. Somebody really dropped the ball at Sony and as a result, they're probably going to lose millions from a tarnished brand name and potential law suits.
Top comments (1)
encrypting != hashing