Javascript – Why almost no webpages hash passwords in the client before submitting (and hashing them again on the server), as to “protect” against password reuse

I usually have a column created TIMESTAMP in a user table so I can see when the user registered. I don't like to add an additional column for Salt, so I use the timestamp column as salt:

SHA1(password + created)

The major mistake you are doing is increasing the opportunity to grab that username/password pair. Even the way SSL works, once authentication has been established, you negotiate a session key for the current collaboration.

The session key is a very important concept, as it can help determine what is a valid session or not. Take the following scenario for example:

• User logs in on one machine, does some stuff and then has to leave it. Stupid him, he forgot to lock the terminal and the session is still active.
• User then logs in on a second machine, and does some more stuff.
• Nefarious user stumbles upon the first machine, and tries to do stuff.

If you use the username/password combo for every request the server can't detect which machine is which--particularly if they are behind the same firewall/gateway. Using a session key that is negotiated each time the user logs in the server can detect which session is which. In fact, when it is properly implemented, the old session key is invalidated so that any future requests using that session key fail.

For your session keys make sure that the following apply:

• It is unique for every username/password combination
• It is unique for each authenticated session
• Old session keys are invalidated and no longer used. (recycling is only OK when the client session mechanisms will fail anyway. I.e. the cookie expires and the server session expires).

This allows a user to move from one machine to another (logging in fresh on each machine), while doing your diligence to prevent someone stealing their session.