diff -r 55968b3205cc -r f10d905e947f handouts/ho01.tex
--- a/handouts/ho01.tex	Fri Sep 26 12:14:41 2014 +0100
+++ b/handouts/ho01.tex	Mon Sep 29 17:43:35 2014 +0100
@@ -491,30 +491,33 @@
 \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). 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 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 
@@ -558,15 +561,29 @@
 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. The moral is that you should
-never store passwords in plain text. Never ever.
+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
 
+\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
+recommendable, though quite expensive.  Clearly, passwords are a
+technology that comes to the end of its usefulness, because brute
+force attacks become more and more powerful and it is unlikely that
+humans get any better in remembering (securely) longer and longer
+passwords. The big question is which technology can replace
+passwords\ldots
 \end{document}
 
 %%% Local Variables: