329 for our web-applications. 

   329 with our web-applications and later with how to store

   330 

   330 passwords properly. 

   335 counter before the hash is calculated. In our case we need to

   335 counter before the hash is calculated. In our case we must

   337 we now need to extract from the cookie the counter value and

   337 we need to extract from the cookie the counter value and the

   338 the hash (Lines 19 and 20). But before has the counter again

   338 hash (Lines 19 and 20). But before hashing the counter again

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

   360 the counter, and also give us confidence that the counter has

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

   361 not been tampered with. This of course depends on being able

   362 keep the salt secret. 

   362 to keep the salt secret. Once this is out, we better ignore

   363 

   363 all cookies and start setting them again with a new salt.

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

   364 

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

   365 There is an interesting and very subtle point to note with

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

   366 respect to the New York Times' way of checking the number

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

   367 visits. Essentially they have their `resource' unlocked at the

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

   368 beginning and lock it only when the data in the cookie states

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

   369 that the allowed free number of visits are up. As said before,

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

   370 this can be easily circumvented by just deleting the cookie or

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

   371 by switching the browser. This would mean the New York Times

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

   372 will lose revenue whenever this kind of tampering occurs. In

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

   373 contrast, our web-application has the resource (discount)

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

   374 locked at the beginning and only unlocks it if the cookie data

   375 No mayor harm will result.

   375 says so. If the cookie is deleted, well then the resource just

   376 

   376 does not get unlocked. No mayor harm will result to us. You

   377 can see: the same security mechanism behaves rather

   378 differently depending on whether the ``resource'' needs to be

   379 locked or unlocked. Apart from think about the difference very

   380 carefully, I do not know of any ``theory'' that could help

   381 with solving such security intricacies in any automatic way.  

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

   385 While admittedly quite silly, the simple web-application in

   381 previous section should help with the more important question

   386 the previous section should help with the more important

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

   387 question of how passwords should be verified and stored. It is

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

   392 password that is already stored for this user in the system.

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

   393 But doing this verification in plain text is really a bad

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

   394 idea. Unfortunately, evidence suggests, however, it is still a

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

   395 widespread practice. I leave you to think about why verifying

   391 verifying passwords in plain text is a bad idea.

   396 passwords in plain text is a bad idea.

   392 

   397 

   393 Using hash functions we can do better.

   398 Using hash functions we can do better. It is not really

   399 necessary to store passwords in plain text in order to verify

   400 whether a password matches. We can just hash the password in

   401 order to be stored. And whenever the user types in a new

   402 password, well then we hash it again and check whether the

   403 hash-values agree. Lets analyse what happens when a hacker

   404 gets hold of our password database. In case the passwords are

   405 hashed, the hacker has a list of user names and associated

   406 hash-values, like 

   407 

   408 \begin{center}

   409 \pcode{urbanc:2aae6c35c94fcfb415dbe95f408b9ce91ee846ed}

   410 \end{center}

   411 

   412 \noindent For a beginner-level hacker this information

   413 is of no use. It would not work to type in the hash value

   414 instead of the password, because it will go through the

   415 hashing function again and then the resulting two

   416 hash-values will not match. One attack a hacker can try is

   417 called a \emph{brute force attack}. Essentially this means

   418 trying out exhaustively all strings

   419 

   420 \begin{center}

   421 \pcode{a},

   422 \pcode{aa},

   423 \pcode{...},

   424 \pcode{ba},

   425 \pcode{...},

   426 \pcode{zzz},

   427 \pcode{...}

   428 \end{center}   

   429 

   430 \noindent hash them and check whether they match with the

   431 hash-values in the database. Such brute force attacks are

   432 surprisingly effective. With modern technology (usually GPU

   433 graphic cards), passwords of moderate length