Binary file handouts/ho01.pdf has changed

--- a/handouts/ho01.tex	Thu Sep 25 06:43:43 2014 +0100
+++ b/handouts/ho01.tex	Thu Sep 25 07:49:22 2014 +0100
@@ -311,7 +311,7 @@
 then graft a cookie accordingly. This is eased by the fact
 that for SHA-1 many strings and corresponding hashvalues are
 precalculated. Type, for example, into Google the hash value
-for \pcode{"hello wolrd"} and you will actually pretty quickly
+for \pcode{"hello world"} and you will actually pretty quickly
 find that it was generated by input string \pcode{"hello
 wolrd"}. This defeats the purpose of a hashing functions and
 thus would not help us for our web-applications. 
@@ -334,6 +334,52 @@
 \caption{\label{hashsalt}}
 \end{figure}
 
+\begin{center}\tt
+\begin{tabular}{l}
+1 + salt - 8189effef4d4f7411f4153b13ff72546dd682c69\\
+2 + salt - 1528375d5ceb7d71597053e6877cc570067a738f\\
+3 + salt - d646e213d4f87e3971d9dd6d9f435840eb6a1c06\\
+4 + salt - 5b9e85269e4461de0238a6bf463ed3f25778cbba\\
+...\\
+\end{tabular}
+\end{center}
+
+\noindent These hashes allow us to read and set the value of
+the counter and give us confidence that the counter has not
+been tampered with. This of course depends on being able to
+keep the salt secret. 
+
+There is an interesting point to note with respect to the New
+York Times' way of checking the number visits. Essentially
+they have their `resource' unlocked at the beginning and lock
+it only when the data in the cookie states the allowed free
+number of visits are up. This can be easily circumvented by
+just deleting the cookie or by switching the browser. This
+would mean the New York Times will loose revenue whenever this
+kind of tampering occurs. In contrast, our web-application has
+the resource (discount) locked at the beginning and only
+unlocks it if the cookie data says so. If the cookie is
+deleted, well then the resource just does not get unlocked.
+No mayor harm will result.
+
+
+\subsection*{How to Store Passwords}
+
+While admittedly silly, the simple web-application in the
+previous section should help with the more important question
+of how passwords should be verified and stored. It is
+unbelievable that nowadays systems still do this with
+passwords in plain text. The idea behind such plain-text
+passwords is of course that if the user typed in \emph{foobar}
+as password, we need to verify whether it matches with the
+password that is stored for this user in the system. But doing
+this verification in plain text is really a bad idea.
+Unfortunately, evidence suggests, however, it is still a
+widespread practice. I leave you to it to think about why
+verifying passwords in plain text is a bad idea.
+
+Using hash functions we can do better.
+
 %The corresponding attack is called \emph{dictionary
 %attack}\ldots hashes are not reversed by brute force
 %calculations, that is trying out all possible combinations.