<rant type="Saturday afternoon">
A key challenge in client/server systems which exchange information over a public network is authenticating users. Typically users are identified by a userid, and authenticate with a password.
For security purposes passwords should never be stored, and so generally the server stores a hash of the password. This enables validation but not recovery; if a user forgets their password it must be reset.
Because public networks are insecure, passwords should never be transmitted over the network, instead, they should be hashed on the client. In addition to eliminating any possibility that passwords could be captured in flight, this also means that any kind of server error would never reveal a password, since the server never even sees them.
Hashing passwords on the client is good, but it leaves the possibility that a hashed password could be intercepted and replayed. To solve this, maybe the current time could be combined with the password before hashing it? Call this H(T+P). But can the server validate this? It knows H(P), and it might be able to guess T (although synchronizing time is never easy), but H(P) and T don't yield H(T+P).
Maybe the current time could be combined with the hash of the password, and that could be hashed again? Call this H(T+H(P)). The server can validate this if it can guess T, because it knows H(P) already. This is secure and makes replays impossible.
So here's the better way to handle passwords:
It's actually not that hard, and nicely secure. You're welcome!
Oh yeah, this is how eyesFinder's authentication works...