In my predictions for 2018 piece yesterday, Nibbles: Breakfast Bytes Predictions for 2018 , I wrote: The first amazing thing about this is that even when I was studying computer science back in stone age, before PCs and smartphones and the internet, Roger Needham, my lecturer on operating systems told us that passwords should always always always be encrypted with a "one-way function" and not stored in the clear. It shouldn't even be possible to generate a list of passwords for security researchers to study. By the way, Roger was a lecturer at the Cambridge Computer Laboratory when I was an undergraduate, went on to become the head of department, then set up Microsoft's UK research laboratory. He died in 2003, young for today at 68. I realize that probably most people don't know anything about how passwords are stored, and it is quite interesting. So that is today's topic. Before going any further, let me point out that if your job is to store passwords on the internet (or anywhere else) then either you should already know everything I say here, or you need to get professional help from someone who knows what they are doing. I think it goes without saying that you should not make your decisions on security based on something you happened to come across "in a blog on the internet". This post is intended to let you know some interesting stuff, and also how to do some limited assessment as to how secure are the systems you use. Password Database Somewhere on the server or the computer system, there is a password file. It contains a list of the usernames and a way to verify the passwords (and some other stuff, like whether you are an admin, or what your account number is). On Unix systems, this was traditionally in a file called /etc/passwd and this file was readable by anyone. So the first thing that is obvious, is that you can't just store the actual passwords in the file, since then anyone could read the file and find out every user's password. These days the requirement for it to be readable by anyone has been obviated. You can even check this, if you are on a mac. Open a terminal window, you can then type ls /etc and you will see a file called master.passwd which I assume is the password file for your own computer, but if you try and read it ( cat /etc/master.passwd ) you will get permission denied. Going back to the original quote from Roger Needham, the passwords should be encrypted with what, in the 1970s, was called a one-way function and is now called a cryptographic hash function. If the passwords were just stored in plain text in the password file, then the login procedure would be something like "take the password typed, and see if it matches the one in the file, and if so let the user log on." With the one-way code, what is stored in the password file (when the user is created or changes their login password) is the password after being passed through the one-way code. So now the login procedure becomes "take the password typed, run it through the one-way code, and see if that matches the one in the file, and if so let the user log on." One-way code, or cryptographic hash functions, are ways of taking the actual characters of the password and turning them into a fixed length (but typically long) number, called the hash. The same characters will always give the same hash. Even a tiny change to the characters typed (changing an "a" to a "b") will result in a hash that is completely different. The one-way nature of the hash function is that even if you find out the value of the hash, there is no way to find out the characters of the password (actually, of course, like with those little bicycle combination locks with four digits, you can try them all, which is why systems make you have long passwords and use a rich alphabet that "must contain a letter, a number, and a special character"). Even Your Bank Doesn't Know Your PIN This is a very important aspect of the way passwords are stored, and worth emphasizing. If you call up your bank and say you forgot your PIN for your debit card, they obviously aren't just going to tell you what it is over the phone. But it is not just that because that would be stupid. The person on the phone with you doesn't have access to your PIN, the computer system won't show it to them. But here is the important part: this is not just because the computer system has been well-written. The bank's computer system doesn't know your PIN either, and has no way to find out. It doesn't need to. When you go to the ATM and type in those numbers, it runs them through the hash function and checks that matches what it has in the database. The one-way function only goes one way. Cracking Passwords There are a number of ways that the bad guy can try and crack someone's password. On a computer system or a smartphone, one way to to try and get in is to try all the passwords. Obviously, on a keyboard, this is completely impractical since there are billions of possible passwords. To make it even more difficult, systems start to slow you down once you get several wrong passwords, making you wait ten seconds, then a minute between attempts. On an iPhone, if you have it enabled (which you should), your phone will actually erase all the data on your phone after 10 failed attempts. So the only practical way to crack a password is to steal the password file and try passwords offline. There are two main ways to do this. One is known as brute force, meaning try all the passwords in order. So start with "a" then "b" and eventually "aa" and so on. The other is called a dictionary attack. Most people's passwords are very simple, words in the dictionary, often changed a little bit (add a digit on the end, make the first character upper case, change "I' to "!", that sort of thing). There are a lot fewer words in the dictionary (even trying common ways they get changed) than in the exhaustive search. A variation, if your system has been compromised, is to try every word in every file on the system, on the basis that you might have put your bank account (or whatever) password in a file (don't). In security, one assumption always made is that the security depends only on the keys used in the encryption algorithm. This has been known for a long time and is called Kerchoff's Principle (after the Dutch cryptographer Auguste Kerchoff, that's him on the right, who published in 1883—I said it was a long time) or Shannon's Maxim (after Claude Shannon, the legendary information theorist who created information theory). It is thus always assumed that the bad guys know the algorithm being used (which cryptographic hash function) and have managed to get a copy of the password database. That is not to say that you shouldn't keep the algorithm secret, and that you shouldn't make the password file inaccessible to ordinary users. Just that the security of the whole system does not depend on those two things remaining secret. Even if they steal the database, and know which algorithm you use, they still should not be able to find out the passwords. The first defense against this is, unlike most of the time in computing, to make the cryptographic hash function really slow, and expensive (in terms of compute time) to calculate. When you log in to your computer or phone, it really doesn't matter if it takes quarter of a second to check the password, it only has to be done once per login. But for the bad guys, trying all the passwords, this might change the number of passwords they can try in a second from a billion to...four. Of course, the bad guys can use multiple computers, but even if they use 1000 then they can only try 4,000 passwords per second. Lookup Tables There is another approach the bad guys can take and that is to precompute all the passwords, or a big subset of them. They run all the possible passwords through the hash function and then keep all the answers. Now, given the hash of a password, they can see if it is in their table, and if so they know the password. In a sense, at the cost of a huge amount of computation, they have made the "one-way" function (partially) two-way. This is most useful if the bad guys have stolen lots of passwords in either a huge password file, or password files from a lot of systems. With almost infinitely cheap computation available through the cloud, this becomes feasible, even with a computationally expensive hash function. Plus, just as with Bitcoin mining, if you want it to go really fast you can use GPUs, build a special FPGA encryption engine, or (at least theoretically) a custom chip. Tomorrow How to use salt to protect against this. Sign up for Sunday Brunch, the weekly Breakfast Bytes email.![]()
↧