337 \begin{center}\tt

   338 \begin{tabular}{l}

   339 1 + salt - 8189effef4d4f7411f4153b13ff72546dd682c69\\

   340 2 + salt - 1528375d5ceb7d71597053e6877cc570067a738f\\

   341 3 + salt - d646e213d4f87e3971d9dd6d9f435840eb6a1c06\\

   342 4 + salt - 5b9e85269e4461de0238a6bf463ed3f25778cbba\\

   343 ...\\

   344 \end{tabular}

   345 \end{center}

   346 

   347 \noindent These hashes allow us to read and set the value of

   348 the counter and give us confidence that the counter has not

   349 been tampered with. This of course depends on being able to

   350 keep the salt secret. 

   351 

   352 There is an interesting point to note with respect to the New

   353 York Times' way of checking the number visits. Essentially

   354 they have their `resource' unlocked at the beginning and lock

   355 it only when the data in the cookie states the allowed free

   356 number of visits are up. This can be easily circumvented by

   357 just deleting the cookie or by switching the browser. This

   358 would mean the New York Times will loose revenue whenever this

   359 kind of tampering occurs. In contrast, our web-application has

   360 the resource (discount) locked at the beginning and only

   361 unlocks it if the cookie data says so. If the cookie is

   362 deleted, well then the resource just does not get unlocked.

   363 No mayor harm will result.

   364 

   365 

   366 \subsection*{How to Store Passwords}

   367 

   368 While admittedly silly, the simple web-application in the

   369 previous section should help with the more important question

   370 of how passwords should be verified and stored. It is

   371 unbelievable that nowadays systems still do this with

   372 passwords in plain text. The idea behind such plain-text

   373 passwords is of course that if the user typed in \emph{foobar}

   374 as password, we need to verify whether it matches with the

   375 password that is stored for this user in the system. But doing

   376 this verification in plain text is really a bad idea.

   377 Unfortunately, evidence suggests, however, it is still a

   378 widespread practice. I leave you to it to think about why

   379 verifying passwords in plain text is a bad idea.

   380 

   381 Using hash functions we can do better.

   382