You could use this to eliminate the risk of session hijacking (e.g. you're on an insecure network like open wifi and someone sniffs your session cookie).

When the user logs in (onsubmit), keep their plaintext password in client-side storage, but otherwise do everything as normal (submit the form, server sends back a Set-Cookie header with a session key). Thereafter, every time you hit the server, the server does a hash of the session key combined with your password (HMAC, ideally) to produce a new session key, but doesn't send a Set-Cookie header with the new value. Instead, javascript in the page (onload or manually after ajax requests) reads the stored password and current session cookie, does the same hashing operation and resets the session cookie client-side so it's ready for the next request.

So the session key changes every request, and each key is only good once.

Of course, you'd also want to make sure the password doesn't get sent in plaintext on the initial login and isn't stored in plaintext on the server. You usually do that on the server side by generating and saving some random salt for each user and then storing a hash of the password combined with that salt instead of the password itself. Then for your login form, onsubmit you first send just the username to the server in an ajax request to get the user-specific salt (which need not be secret) and a nonce. Then you create the same hash of password+salt in javascript to get the value that's stored on the server, and then you generate a hash of that value combined with the nonce and send that back to the server with the nonce itself. The server makes sure the nonce is valid, then does its own hash of the user's salted password hash it has combined with the nonce and compares that to the value your javascript came up with. If it matches, the password was good and the server sends the initial session cookie.

(In the ajax request to get the user-specific salt, if the username is invalid you have the server just return a random value that looks like salt. That way an attacker can't tell if they've got a correct username.)

In this case, you'd store the salted password hash (which the server also knows) client-side and use that to rehash the session key each request.

For best results, fall back to a traditional session cookie scheme for people without javascript (e.g. if you get a vanilla login form submission at the server instead of the expected ajax hits, flag that session as non-javascript and don't change the session key with each request).

Won't quite work with OpenID, though. The browser and the server need a shared secret. I guess you could do a Diffie-Hellman key exchange via ajax right after the login. Or just send a random shared secret in a cookie alongside the initial session key and hope no one notices.

Or use SSL.

Just thought I'd share that.