LinkedIn gave up password hashes for around 8 million passwords. The leaks for the data don’t seem to include usernames, but the holders of the information state they have it.When news sites say someone lost “encrypted passwords”, understand that Encryption allows to reverse the algorithm to get the plaintext. But with hashing algorithm, it is not possible.
The way LinkedIn stored passwords was insecure. Hashing the same data with the same algorithm produces the same result always. It is common for security groups (blackhats, whitehats, and grayhats) to spend a lot of time computing hashes of what they believe would be common passwords and storing these in a Rainbow Table.
If I see the hash for the password “password1234” in a password dump, I know that 1) either your password is "password1234", or 2) password1234 will also work as your password. The secure way to store a password is to concatenate a “salt” to the password to make the hash entirely different before doing the hashing (and multiple rounds), and store this salt with the hash so that rainbow tables are not effective, and so brute force is required to get the password. (There are even more secure ways by keeping additional salt material outside the database, but that’s beside the point).
So out of the millions of stolen passwords, attackers have already gotten the plaintext for 60-80% of them.
So what’s the lesson? Use a password database. There are a few benefits to this: 1) Your password will likely be more secure than one you would come up with on your own, and less likely to appear in a rainbow table, and less likely to be brute-forced soon 2) When something like this happens, you don’t have to devise a new password “scheme” or just “add 1” or something - you just generate a brand new password and call it a day. 3) You can use a different password for every single thing you need a password for. So if the attackers get your email address, they don’t also have your email password (or the user ID and password you use for ebay or paypal)
The way LinkedIn stored passwords was insecure. Hashing the same data with the same algorithm produces the same result always. It is common for security groups (blackhats, whitehats, and grayhats) to spend a lot of time computing hashes of what they believe would be common passwords and storing these in a Rainbow Table.
If I see the hash for the password “password1234” in a password dump, I know that 1) either your password is "password1234", or 2) password1234 will also work as your password. The secure way to store a password is to concatenate a “salt” to the password to make the hash entirely different before doing the hashing (and multiple rounds), and store this salt with the hash so that rainbow tables are not effective, and so brute force is required to get the password. (There are even more secure ways by keeping additional salt material outside the database, but that’s beside the point).
So out of the millions of stolen passwords, attackers have already gotten the plaintext for 60-80% of them.
So what’s the lesson? Use a password database. There are a few benefits to this: 1) Your password will likely be more secure than one you would come up with on your own, and less likely to appear in a rainbow table, and less likely to be brute-forced soon 2) When something like this happens, you don’t have to devise a new password “scheme” or just “add 1” or something - you just generate a brand new password and call it a day. 3) You can use a different password for every single thing you need a password for. So if the attackers get your email address, they don’t also have your email password (or the user ID and password you use for ebay or paypal)
No comments:
Post a Comment