By now, as the end of the first quarter of the 21st century draws near, everyone is surely aware that user passwords are digital gold, and that protecting them is a key aspect of ensuring data security and privacy. Yet despite this, not all companies store passwords properly still.<\/p>\n
In this post we look at how NOT to store user passwords, and what methods are used by services that take security seriously.<\/p>\n
The simplest method is to store passwords in an unencrypted database. When a user tries to sign in, authentication is just a matter of matching what they enter against what\u2019s in the database.<\/p>\n
But there\u2019s always a risk that attackers might steal this database one way or another \u2014 for example, by exploiting vulnerabilities in the database software. Or a password table might get stolen by an ill-intentioned employee with high access privileges. Also leaked or intercepted employee credentials could be used to steal passwords. Put simply, there are plenty of scenarios where things can go pear-shaped. Remember: data stored in open form is precisely that \u2014 open.<\/p>\n
What if you store passwords in encrypted form? Not a bad idea at first glance, but it doesn\u2019t work great in practice. After all, if you store encrypted passwords in the database, they have to be decrypted each and every time to compare them with user input.<\/p>\n
And that means the encryption key will be somewhere close by. If that\u2019s the case, this key can easily fall into hackers\u2019 hands along with the password database. So, that defeats the whole purpose: the cybercriminals will be able to quickly decrypt this database and get passwords in plaintext, so we end up back where we started.<\/p>\n
As cryptographers jest in all seriousness, encryption doesn\u2019t solve the problem of data privacy \u2014 it just makes it a problem of secure key storage. You can come up with some sort of cunning schemes that may reduce the risks, but in general it won\u2019t be possible to reliably secure passwords this way.<\/p>\n
The best method is not to store passwords at all. If you don\u2019t have something \u2014 it can\u2019t get stolen, right?<\/p>\n
But how to check whether a signing-in user has entered the correct password? That\u2019s where hash functions<\/a> come into play: special cryptographic algorithms that scramble any data into a fixed-length string of bits in a predictable but irreversible way.<\/p>\n Predictable<\/em> here means that the same data is always converted into the same hash. And irreversible<\/em> means that it\u2019s completely impossible to recover the hashed data from the hash. That\u2019s what any online service does if it cares about user data even just a tiny bit and values its reputation.<\/p>\n When a user creates a password during registration \u2014 not the password itself but its hash is stored in the database along with the username. Then, during the sign-in process this hash is compared against the hash of the password entered by the user. If they match, it means the passwords are the same.<\/p>\n In the event of a database leak, it\u2019s not the passwords that the attackers get hold of, but their hashes, from which the original data cannot be recovered (irreversibility, remember?). Of course, this is a vast improvement security-wise, but it\u2019s still too soon to rejoice: if the cybercriminals get their hands on the hashes, they might attempt a brute-force attack.<\/p>\n After obtaining your database, the hackers might try to extract the passwords through brute force. This means taking a combination of characters, calculating its hash, and looking for matches across all entries in the database. If no matches are found, they\u2019ll try another combination, and so on. If there\u2019s a match, the password that was used to calculate the hash in the database is now known.<\/p>\n Worse still, the process of cracking hashed passwords can be sped up considerably by means of so-called rainbow tables. Rainbow tables are huge data arrays with precalculated hash functions for most frequently met passwords. As such, they make it easy to search for matches in the stolen database. And it\u2019s all done automatically, of course, so the password-cracking process becomes too quick for comfort.<\/p>\n However, there is some good news: it\u2019s impossible to calculate the hashes of all possible character combinations in advance \u2014 a complete rainbow table<\/a> for any hashing algorithm will take up more disk space than there is on the planet. Even for the not-overly-reliable MD5 algorithm, such a hypothetical table would contain (deep breath) 340\u00a0282\u00a0366\u00a0920\u00a0938\u00a0463\u00a0463\u00a0374\u00a0607\u00a0431\u00a0768\u00a0211\u00a0456 records. Which is why only the most common combinations get included in rainbow tables. <\/p>\n To combat the use of rainbow tables, cryptographers came up with a solution that utilizes another important property of hash functions: even the tiniest change in the source text alters the hashing result beyond all recognition.<\/p>\nThe even better way: salted hashes<\/h2>\n