--- a/handouts/ho01.tex Tue Jan 05 01:37:31 2016 +0000
+++ b/handouts/ho01.tex Mon Jan 11 02:05:24 2016 +0000
@@ -30,6 +30,9 @@
They just can't help it.''
\end{quote}
+\noindent
+and
+
\begin{quote}
\it ``Security engineering\ldots requires you to think
differently. You need to figure out not how something works,
@@ -45,16 +48,16 @@
\noindent In this module I like to teach you this security
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
+hack into things. However, 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 by hiding notes or by looking over the
shoulders of your fellow pupils). Right? To defend a system,
-you need to have this kind of 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
-security mechanisms made a system actually less
+you need to have this kind of 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 security mechanisms made a system actually less
secure.\medskip
\noindent
@@ -162,7 +165,10 @@
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.
+customer who used a card or not. The current state of affairs,
+however, is that standing up for your right requires you
+to be knowledgeable\ldots{}if not, the banks are happy to
+take advantage of you.
This is a classic example where a security design principle
was violated: Namely, the one who is in the position to
@@ -225,7 +231,9 @@
executed whenever a browser initiates such a GET request. You
can run this program on your computer and then direct a
browser to the address \pcode{localhost:8000} in order to
-simulate a request over the internet.
+simulate a request over the internet. You are encouraged
+to try this out\ldots{}theory is always good, but practice is
+better.
For our web-application of interest is the feature that the
@@ -302,18 +310,14 @@
resistance}. Cryptographic hash functions also ensure that
given a message and a hash, it is computationally infeasible to
find another message with the same hash. This is called
-\emph{collusion resistance}. Because of these properties hash
+\emph{collusion resistance}. Because of these properties, hash
functions are often called \emph{one-way functions}: you
cannot go back from the output to the input (without some
tricks, see below).
-
-
-
-
-There are several such
-hashing function. For example SHA-1 would hash the string
-\pcode{"hello world"} to produce the hash-value
+There are several such hashing function. For example SHA-1
+would hash the string \pcode{"hello world"} to produce the
+hash-value
\begin{center}
\pcode{2aae6c35c94fcfb415dbe95f408b9ce91ee846ed}
@@ -342,26 +346,25 @@
\pcode{1-356a192b7913b04c54574d18c28d46e6395428ab}
\end{center}
-\noindent If we now read back the
-cookie when the client visits our webpage, we can extract the
-counter, hash it again and compare the result to the stored
-hash value inside the cookie. If these hashes disagree, then
-we can deduce that the cookie has been tampered with.
-Unfortunately, if they agree, we can still not be entirely
-sure that not a clever hacker has tampered with the cookie.
-The reason is that the hacker can see the clear text part of
-the cookie, say \pcode{3}, and also its hash. It does not take
-much trial and error to find out that we used the SHA-1
-hashing function and then the hacker can graft a cookie
-accordingly. This is eased by the fact that for SHA-1 many
-strings and corresponding hash-values are precalculated. Type,
-for example, into Google the hash value for \pcode{"hello
-world"} and you will actually pretty quickly find that it was
-generated by input string \pcode{"hello world"}. Similarly for
-the hash-value for \pcode{1}. This defeats the purpose of a
-hashing function and thus would not help us with our
-web-applications and later also not with how to store
-passwords properly.
+\noindent If we now read back the cookie when the client
+visits our webpage, we can extract the counter, hash it again
+and compare the result to the stored hash value inside the
+cookie. If these hashes disagree, then we can deduce that the
+cookie has been tampered with. Unfortunately, if they agree,
+we can still not be entirely sure that not a clever hacker has
+tampered with the cookie. The reason is that the hacker can
+see the clear text part of the cookie, say \pcode{3}, and also
+its hash. It does not take much trial and error to find out
+that we used the SHA-1 hashing function and then the hacker
+can graft a cookie accordingly. This is eased by the fact that
+for SHA-1 many strings and corresponding hash-values are
+precalculated. Type, for example, into Google the hash value
+for \pcode{"hello world"} and you will actually pretty quickly
+find that it was generated by input string \pcode{"hello
+world"}. Similarly for the hash-value for \pcode{1}. This
+defeats the purpose of a hashing function and thus would not
+help us with our web-applications and later also not with how
+to store passwords properly.
There is one ingredient missing, which happens to be called
@@ -406,10 +409,10 @@
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. The
-quick fix to require that a cookie must always be present does
-not work, because then this newspaper will cut off any new
-readers, or anyone who gets a new computer. In contrast, our
-web-application has the resource (discount) locked at the
+`quick fix' to require that a cookie must always be present
+does not work, because then this newspaper will cut off any
+new readers, or anyone who gets a new computer. 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 major harm will result to us. You can see:
@@ -609,6 +612,13 @@
\end{center}
\noindent
+A recent research paper about surveillance using cookies is
+
+\begin{center}
+\url{http://randomwalker.info/publications/cookie-surveillance-v2.pdf}
+\end{center}
+
+\noindent
A slightly different point of view about the economies of
password cracking:
@@ -649,13 +659,6 @@
passwords\ldots
\medskip
-\noindent
-A recent research paper about surveillance using cookies is
-
-\begin{center}
-\url{http://randomwalker.info/publications/cookie-surveillance-v2.pdf}
-\end{center}
-
\end{document}