A user enters their password, and submits the login form. The password is sent to the server, authentication is run, and the hashed password matches the one stored in the database.
This is where what I am wondering comes into play. What I want to know is if this scenario would be useful:
The user’s password is then re-hashed with a new random salt, and the original hash stored in the database is overwritten. Next time the user logs in, they still enter the exact same password, but a different hash is being checked.
Please let me know if this would be a more secure approach to password hashing.
EDIT
I wrote this question very poorly…. I have been researching methods to make non-SSL login scripts more secure, and came upon an idea to use javascript to hash the password before it was sent via post data. This struck me as a semi-decent idea, except it would be pointless if the hacker intercepted the hashed post data, because he could just sent fake post data from then on using the hash. I got to thinking about re-hashing the pass with a new salt every time, so the hacker would have to continuously re-sniff the connection every time he wanted access to that user’s account.
This way, without a key-logger or some sort of client-side software on the victim’s computer, a hacker wouldn’t be able to get access to the client’s password, and thus would only be able to access one session at a time, as soon as the user logged in, the hash would change the the hacker would have had to been listening when the user logged in again to get the new hash.
The only difference I can see here is that the salted hashes in the database would change regularly.
So, each attacker who somehow manages to read the database would have another set of hashes to bruteforce. But, when one of the hashes is broken (e.g. you found a password which together with the salt gives the given hash), it most probably is the original password, and it will continue to work even if the salt and hash in the database changes later.
So, no change in security here.