Where is the password hash calculated, locally on or the server? My computer security professor uses the following notation, where S denotes a server and A denoted Alice. Alice wants to authenticate herself to the server. The hash function is a hash chain where $h^n(x)$ denotes a hash function $h(h(h(..h_n(x)..)))$. $n$ is stored on the server.

Assignment:


  The following authentication protocol makes use of the Lamport hash
  construction (sometimes simply called ‘hash chain’). The construction simply consists of repeat-
  edly applying a hash function to an input value. We write h n (x) to denote hashing x n times,
  e.g. h 3 (x) = h(h(h(x))). Each user chooses a password pw and hashes this n times. He/she then
  sends it to the server. Let us assume that initially, n = 10 000. The server then stores a tuple
  (user, n, Y = h n (pw)) for each user in a database. Users can now authenticate to the server using
  the following protocol: The server checks if h(X) = Y , then decrements n and sets Y := X. So, after a successful run of
  this protocol the server holds a new tuple (user, n − 1, Y = h n−1 (pw)).


$ A \longrightarrow S : \text{I want to authenticate} \\
S \longrightarrow A : n\\
A \longrightarrow S : X = h^{n-1}(\text{password}) 
$ 

So now the hash is calculated on the device Alice uses. I am a bit confused now, because I always would receive the user's plain-text password and then hash it and store it in a database instead of receiving the password from the user. Also, I don't think this is possible at all in a web application. 

My question is whether or not this protocol is used, and if so how would it be implemented. Also, what is more secure, hashing on the user side or the server side?
I can imagine a protocol like this, where $n$ starts from a high value, and gets decremented by the server at each login attempt. Characteristically:


The system has a degree of resistance against passive eavesdropping, which is no more susceptible to password search than server-side iterated hash is should the hashed password leak. That's a significant security benefit (especially if the client implements a minimum on $n$, which at least prevents a Man-in-the-Middle to find the password without heavy search; beware however that it does not prevent the MitM from obtaining a hash allowing to log-in many times).
The server can verify the password with one hash (or $k+1$ hashes if there has been $k$ consecutive failed logins). The bulk of the password hashing work is on the client side, which is a benefit for the server.
As long as $n$ remains high, and salt is used (there's none in the question), leak of the password database is no worse than in a normal system with hash on the server.


I have never seen this used. Main problem is, there's no support in browsers, thus the code doing the hashing on the client side will be JavaScript (for acceptability by users/prescriber), thus


that code is at best authenticated using https, and then there is little security benefit compared to password in clear over https, which is the norm.
JavaScript is sizably less efficient than native (the difference used to be huge, and still is on many platforms/devices), and the number of iterations much be chosen low enough to be acceptable on the less efficient platform.


About the same issues have killed all attempts to use PAKE that I have seen.

Also, the question's system is not really immune against active attackers able to impersonate the server, which is a serious drawback compared to some other PAKE. And password search is still possible from passive eavesdropping, which other PAKE manage to avoid.