diff -r 01fe5aba8781 -r 7807863c4196 handouts/ho01.tex --- a/handouts/ho01.tex Tue Oct 07 12:48:07 2014 +0100 +++ b/handouts/ho01.tex Thu Oct 09 14:41:36 2014 +0100 @@ -42,7 +42,7 @@ hack into things. I beg to differ: You have this mindset already when in school you were thinking, at least hypothetically, about ways in which you can cheat in an exam -(whether it is about hiding notes or looking over the +(whether it is by hiding notes or by looking over the shoulders of your fellow pupils). Right? To defend a system, you need to have this kind mindset and be able to think like an attacker. This will include understanding techniques that @@ -108,7 +108,7 @@ authorisation. Even though the banks involved trumpeted their system as being absolutely secure and indeed fraud rates initially went down, security researchers were not convinced -(especially the group around Ross Anderson). To begin with, +(especially not the group around Ross Anderson). To begin with, the Chip-and-PIN system introduced a ``new player'' into the system that needed to be trusted: the PIN terminals and their manufacturers. It was claimed that these terminals were @@ -122,7 +122,7 @@ mostly beyond the control of customers who need to use these terminals. -To make matters worse for Chip-and-PIN, in around 2009 Ross +To make matters worse for Chip-and-PIN, around 2009 Ross Anderson and his group were able to perform man-in-the-middle attacks against Chip-and-PIN. Essentially they made the terminal think the correct PIN was entered and the card think @@ -148,15 +148,15 @@ Since banks managed to successfully claim that their Chip-and-PIN system is secure, they were under the new system able to point the finger at the customer when fraud occurred: -customers must have been negligent losing their PIN and they -had almost no way of defending themselves in such situations. -That is why the work of \emph{ethical} hackers like Ross -Anderson's group was so important, because they and others -established that the bank's claim that their system is secure -and it must have been the customer's fault, was bogus. In 2009 -the law changed and the burden of proof went back to the -banks. They need to prove whether it was really the customer -who used a card or not. +customers must have been negligent losing their PIN and +customers had almost no way of defending themselves in such +situations. That is why the work of \emph{ethical} hackers +like Ross Anderson's group was so important, because they and +others established that the banks' claim that their system is +secure and it must have been the customer's fault, was bogus. +In 2009 the law changed and the burden of proof went back to +the banks. They need to prove whether it was really the +customer who used a card or not. This is a classic example where a security design principle was violated: Namely, the one who is in the position to @@ -183,7 +183,7 @@ \subsection*{Of Cookies and Salts} -Lets look at another example which will help with +Let us look at another example which will help with understanding how passwords should be verified and stored. Imagine you need to develop a web-application that has the feature of recording how many times a customer visits a page. @@ -271,7 +271,7 @@ the server's perspective is a potentially hostile environment. What we need to ensure is the integrity of this counter in this hostile environment. We could think of encrypting the -counter. But this has two drawbacks to do with the key for +counter. But this has two drawbacks to do with the keys for encryption. If you use a single, global key for all the clients that visit our site, then we risk that our whole ``business'' might collapse in the event this key gets known @@ -410,8 +410,8 @@ \pcode{foobar} as password, we need to verify whether it matches with the password that is already stored for this user in the system. Why not doing this with plain-text passwords? -But doing this verification in plain text is really a bad -idea. Unfortunately, evidence suggests it is still a +Unfortunately doing this verification in plain text is really +a bad idea. Alas, evidence suggests it is still a widespread practice. I leave you to think about why verifying passwords in plain text is a bad idea. @@ -481,43 +481,46 @@ as possible of such likely candidates of passwords and also compute their hash-values. The difference between a brute force attack, where maybe $2^{80}$ many strings need to be -considered, a dictionary attack might get away witch checking -only 10 Million (remember the language English ``only'' -contains 600,000 words). This is a drastic simplification for -attackers. Now if the attacker knows the hash-value of a -password is +considered, is that a dictionary attack might get away with +checking only 10 Million words (remember the language English +``only'' contains 600,000 words). This is a drastic +simplification for attackers. Now, if the attacker knows the +hash-value of a password is \begin{center} \pcode{5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8} \end{center} -\noindent then just a lookup in the dictionary will reveal that the -plain-text password was \pcode{password}. What is good about this -attack is that the dictionary can be precompiled in the ``comfort of -the hacker's home'' before an actual attack is launched. It just needs -sufficient storage space, which nowadays is pretty cheap. A hacker -might in this way not be able to crack all passwords in our database, -but even being able to crack 50\% can be serious damage for a large -company (because then you have to think about how to make users to -change their old passwords---a major hassle). And hackers are very -industrious in compiling these dictionaries: for example they -definitely include variations like \pcode{passw0rd} and also include -rules that cover cases like \pcode{passwordpassword} or -\pcode{drowssap} (password reversed).\footnote{Some entertaining rules - for creating effective dictionaries are described in the book - ``Applied Cryptography'' by Bruce Schneier (in case you can find it - in the library), and also in the original research literature which - can be accessed for free from - \url{http://www.klein.com/dvk/publications/passwd.pdf}.} -Historically, compiling a list for a dictionary attack is not as -simple as it might seem. At the beginning only ``real'' dictionaries -were available (like the Oxford English Dictionary), but such -dictionaries are not ``optimised'' for the purpose of passwords. The -first real hard data about actually used passwords was obtained when a -company called RockYou ``lost'' 32 Million plain-text passwords. With -this data of real-life passwords, dictionary attacks took -off. Compiling such dictionaries is nowadays very easy with the help -of off-the-shelf tools. +\noindent then just a lookup in the dictionary will reveal +that the plain-text password was \pcode{password}. What is +good about this attack is that the dictionary can be +precompiled in the ``comfort of the hacker's home'' before an +actual attack is launched. It just needs sufficient storage +space, which nowadays is pretty cheap. A hacker might in this +way not be able to crack all passwords in our database, but +even being able to crack 50\% can be serious damage for a +large company (because then you have to think about how to +make users to change their old passwords---a major hassle). +And hackers are very industrious in compiling these +dictionaries: for example they definitely include variations +like \pcode{passw0rd} and also include rules that cover cases +like \pcode{passwordpassword} or \pcode{drowssap} (password +reversed).\footnote{Some entertaining rules for creating +effective dictionaries are described in the book ``Applied +Cryptography'' by Bruce Schneier (in case you can find it in +the library), and also in the original research literature +which can be accessed for free from +\url{http://www.klein.com/dvk/publications/passwd.pdf}.} +Historically, compiling a list for a dictionary attack is not +as simple as it might seem. At the beginning only ``real'' +dictionaries were available (like the Oxford English +Dictionary), but such dictionaries are not optimised for the +purpose of cracking passwords. The first real hard data about actually +used passwords was obtained when a company called RockYou +``lost'' 32 Million plain-text passwords. With this data of +real-life passwords, dictionary attacks took off. Compiling +such dictionaries is nowadays very easy with the help of +off-the-shelf tools. These dictionary attacks can be prevented by using salts. Remember a hacker needs to use the most likely candidates @@ -544,7 +547,7 @@ \noindent where the first part is the login-name, followed by a field \pcode{$6$} which specifies which hash-function is used. After that follows the salt \pcode{3WWbKfr1} and after -that the hash-value that is stored for the password ( which +that the hash-value that is stored for the password (which includes the salt). I leave it to you to figure out how the password verification would need to work based on this data. @@ -561,18 +564,20 @@ will be associated with a different hash-value. This will make the life harder for an attacker. -Note another interesting point. The web-application from the previous -section was only secure when the salt was secret. In the password -case, this is not needed. The salt can be public as shown above in the -Unix password file where is actually stored as part of the password -entry. Knowing the salt does not give the attacker any advantage, but -prevents that dictionaries can be precompiled. While salts do not -solve every problem, they help with protecting against dictionary -attacks on password files. It protects people who have the same -passwords on multiple machines. But it does not protect against a -focused attack against a single password and also does not make poorly -chosen passwords any better. Still the moral is that you should never -store passwords in plain text. Never ever.\medskip +Note another interesting point. The web-application from the +previous section was only secure when the salt was secret. In +the password case, this is not needed. The salt can be public +as shown above in the Unix password file where it is actually +stored as part of the password entry. Knowing the salt does +not give the attacker any advantage, but prevents that +dictionaries can be precompiled. While salts do not solve +every problem, they help with protecting against dictionary +attacks on password files. It protects people who have the +same passwords on multiple machines. But it does not protect +against a focused attack against a single password and also +does not make poorly chosen passwords any better. Still the +moral is that you should never store passwords in plain text. +Never ever.\medskip \noindent If you want to know more about passwords I recommend viewing some