
diff -r cceb3d2dcba0 -r 67d7d239c617 handouts/ho01.tex
--- 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}
 




