sen-material: comparison handouts/ho01.tex

equal deleted inserted replaced

-:01fe5aba8781
+:7807863c4196
 mindset. This might be a mindset that you think is very
 foreign to you---after all we are all good citizens and not
 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
 can be used to compromise security and privacy in systems.
 This will many times result in insights where well-intended
 Chip-and-PIN, as the name suggests, relies on data being
 stored on a chip on the card and a PIN number for
 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
 tamper-resistant, but needless to say this was a weak link in
 the system, which criminals successfully attacked. Some
 Chip-and-PIN, you need to be able to vet quite closely the
 supply chain of such terminals. This is something that is
 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
 that a signature was used. This is a kind of \emph{protocol
 failure}. After discovery, the flaw was mitigated by requiring
 profits too much.
 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
+customers must have been negligent losing their PIN and
-had almost no way of defending themselves in such situations.
+customers had almost no way of defending themselves in such
-That is why the work of \emph{ethical} hackers like Ross
+situations. That is why the work of \emph{ethical} hackers
-Anderson's group was so important, because they and others
+like Ross Anderson's group was so important, because they and
-established that the bank's claim that their system is secure
+others established that the banks' claim that their system is
-and it must have been the customer's fault, was bogus. In 2009
+secure and it must have been the customer's fault, was bogus.
-the law changed and the burden of proof went back to the
+In 2009 the law changed and the burden of proof went back to
-banks. They need to prove whether it was really the customer
+the banks. They need to prove whether it was really the
-who used a card or not.
+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
 improve security, also needs to bear the financial losses if
 things go wrong. Otherwise, you end up with an insecure
 signature-based method. The customer could now lose
 significant amounts of money.
 \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.
 For example in order to give a discount whenever the customer
 has visited a webpage some $x$ number of times (say $x$ equal
 tampering with cookies, because the whole purpose of cookies
 is that they are stored on the client's side, which from the
 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
 to the outside world. Then all cookies we might have set in
 the past, can now be decrypted and manipulated. If, on the
 passwords in plain text. The idea behind such plain-text
 passwords is of course that if the user typed in
 \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
+Unfortunately doing this verification in plain text is really
-idea. Unfortunately, evidence suggests it is still a
+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.
 Using hash functions, like in our web-application, we can do
 better. They allow us to not having to store passwords in
 \noindent So an attacker just needs to compile a list as large
 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
+considered, is that a dictionary attack might get away with
-only 10 Million (remember the language English ``only''
+checking only 10 Million words (remember the language English
-contains 600,000 words). This is a drastic simplification for
+``only'' contains 600,000 words). This is a drastic
-attackers. Now if the attacker knows the hash-value of a
+simplification for attackers. Now, if the attacker knows the
-password is
+hash-value of a password is
 \begin{center}
 \pcode{5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8}
 \end{center}
-\noindent then just a lookup in the dictionary will reveal that the
+\noindent then just a lookup in the dictionary will reveal
-plain-text password was \pcode{password}. What is good about this
+that the plain-text password was \pcode{password}. What is
-attack is that the dictionary can be precompiled in the ``comfort of
+good about this attack is that the dictionary can be
-the hacker's home'' before an actual attack is launched. It just needs
+precompiled in the ``comfort of the hacker's home'' before an
-sufficient storage space, which nowadays is pretty cheap. A hacker
+actual attack is launched. It just needs sufficient storage
-might in this way not be able to crack all passwords in our database,
+space, which nowadays is pretty cheap. A hacker might in this
-but even being able to crack 50\% can be serious damage for a large
+way not be able to crack all passwords in our database, but
-company (because then you have to think about how to make users to
+even being able to crack 50\% can be serious damage for a
-change their old passwords---a major hassle).  And hackers are very
+large company (because then you have to think about how to
-industrious in compiling these dictionaries: for example they
+make users to change their old passwords---a major hassle).
-definitely include variations like \pcode{passw0rd} and also include
+And hackers are very industrious in compiling these
-rules that cover cases like \pcode{passwordpassword} or
+dictionaries: for example they definitely include variations
-\pcode{drowssap} (password reversed).\footnote{Some entertaining rules
+like \pcode{passw0rd} and also include rules that cover cases
-for creating effective dictionaries are described in the book
+like \pcode{passwordpassword} or \pcode{drowssap} (password
-``Applied Cryptography'' by Bruce Schneier (in case you can find it
+reversed).\footnote{Some entertaining rules for creating
-in the library), and also in the original research literature which
+effective dictionaries are described in the book ``Applied
-can be accessed for free from
+Cryptography'' by Bruce Schneier (in case you can find it in
-\url{http://www.klein.com/dvk/publications/passwd.pdf}.}
+the library), and also in the original research literature
-Historically, compiling a list for a dictionary attack is not as
+which can be accessed for free from
-simple as it might seem. At the beginning only ``real'' dictionaries
+\url{http://www.klein.com/dvk/publications/passwd.pdf}.}
-were available (like the Oxford English Dictionary), but such
+Historically, compiling a list for a dictionary attack is not
-dictionaries are not ``optimised'' for the purpose of passwords. The
+as simple as it might seem. At the beginning only ``real''
-first real hard data about actually used passwords was obtained when a
+dictionaries were available (like the Oxford English
-company called RockYou ``lost'' 32 Million plain-text passwords. With
+Dictionary), but such dictionaries are not optimised for the
-this data of real-life passwords, dictionary attacks took
+purpose of cracking passwords. The first real hard data about actually
-off. Compiling such dictionaries is nowadays very easy with the help
+used passwords was obtained when a company called RockYou
-of off-the-shelf tools.
+``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
 of passwords and calculate their hash-value. If we add before
 hashing a password a random salt, like \pcode{mPX2aq},
 \end{center}
 \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.
 There is a non-obvious benefit of using a separate salt for
 each password. Recall that \pcode{123456} is a popular
 possible if each password gets its own salt: since we assume
 the salt is generated randomly, each version of \pcode{123456}
 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
+Note another interesting point. The web-application from the
-section was only secure when the salt was secret. In the password
+previous section was only secure when the salt was secret. In
-case, this is not needed. The salt can be public as shown above in the
+the password case, this is not needed. The salt can be public
-Unix password file where is actually stored as part of the password
+as shown above in the Unix password file where it is actually
-entry. Knowing the salt does not give the attacker any advantage, but
+stored as part of the password entry. Knowing the salt does
-prevents that dictionaries can be precompiled. While salts do not
+not give the attacker any advantage, but prevents that
-solve every problem, they help with protecting against dictionary
+dictionaries can be precompiled. While salts do not solve
-attacks on password files. It protects people who have the same
+every problem, they help with protecting against dictionary
-passwords on multiple machines. But it does not protect against a
+attacks on password files. It protects people who have the
-focused attack against a single password and also does not make poorly
+same passwords on multiple machines. But it does not protect
-chosen passwords any better. Still the moral is that you should never
+against a focused attack against a single password and also
-store passwords in plain text. Never ever.\medskip
+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
 youtube videos from the PasswordCon(ference) which takes place each
 year. The book by Bruce Schneier about Applied Cryptography is also

changeset 227	7807863c4196
parent 186	f7aa15984301
child 262	57269d9931da