--- a/handouts/ho01.tex Thu Sep 25 11:33:45 2014 +0100
+++ b/handouts/ho01.tex Thu Sep 25 14:39:56 2014 +0100
@@ -326,16 +326,16 @@
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.
-
+with our web-applications and later with how to store
+passwords properly.
There is one ingredient missing, which happens to be called
\emph{salts}. Salts are random keys, which are added to the
-counter before the hash is calculated. In our case we need to
+counter before the hash is calculated. In our case we must
keep the salt secret. As can be see in Figure~\ref{hashsalt},
-we now need to extract from the cookie the counter value and
-the hash (Lines 19 and 20). But before has the counter again
+we need to extract from the cookie the counter value and the
+hash (Lines 19 and 20). But before hashing the counter again
(Line 22) we need to add the secret salt. Similarly, when we
set the new increased counter, we will need to add the salt
before hashing (this is done in Line 15). Our web-application
@@ -357,40 +357,80 @@
\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.
+the counter, and also give us confidence that the counter has
+not been tampered with. This of course depends on being able
+to keep the salt secret. Once this is out, we better ignore
+all cookies and start setting them again with a new salt.
-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.
-
+There is an interesting and very subtle 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
+that the allowed free number of visits are up. As said before,
+this can be easily circumvented by just deleting the cookie or
+by switching the browser. This would mean the New York Times
+will lose 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 to us. You
+can see: the same security mechanism behaves rather
+differently depending on whether the ``resource'' needs to be
+locked or unlocked. Apart from think about the difference very
+carefully, I do not know of any ``theory'' that could help
+with solving such security intricacies in any automatic way.
\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
+While admittedly quite 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.
+password that is already 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 think about why verifying
+passwords in plain text is a bad idea.
+
+Using hash functions we can do better. It is not really
+necessary to store passwords in plain text in order to verify
+whether a password matches. We can just hash the password in
+order to be stored. And whenever the user types in a new
+password, well then we hash it again and check whether the
+hash-values agree. Lets analyse what happens when a hacker
+gets hold of our password database. In case the passwords are
+hashed, the hacker has a list of user names and associated
+hash-values, like
+
+\begin{center}
+\pcode{urbanc:2aae6c35c94fcfb415dbe95f408b9ce91ee846ed}
+\end{center}
-Using hash functions we can do better.
+\noindent For a beginner-level hacker this information
+is of no use. It would not work to type in the hash value
+instead of the password, because it will go through the
+hashing function again and then the resulting two
+hash-values will not match. One attack a hacker can try is
+called a \emph{brute force attack}. Essentially this means
+trying out exhaustively all strings
+
+\begin{center}
+\pcode{a},
+\pcode{aa},
+\pcode{...},
+\pcode{ba},
+\pcode{...},
+\pcode{zzz},
+\pcode{...}
+\end{center}
+
+\noindent hash them and check whether they match with the
+hash-values in the database. Such brute force attacks are
+surprisingly effective. With modern technology (usually GPU
+graphic cards), passwords of moderate length
%The corresponding attack is called \emph{dictionary
%attack}\ldots hashes are not reversed by brute force