Plain WRONG. Even the guy knows it: " Note that a hacker could still sniff the hashed password going over the network, and use that hash later to send to the server and impersonate you. But at least the hacker can't use your real password for other purposes."
You can try with two salts. One of them must be one time random for each auth request. Then you apply the hashing twice with the 2 salts on the client and once on the server with the one time only. mic Il giorno 21/set/2011 14:48, "Anthony" <[email protected]> ha scritto: > +1 > > On Wednesday, September 21, 2011 2:43:20 AM UTC-4, pbreit wrote: >> >> It might not be a bad idea to improve password handling at this time. I >> think the biggest problem is that password hases are not currently salted. >> The hmac_hash function appears to take a salt but I didn't see any evidence >> that is ever actually used. >> >> The Django model seems sufficient: >> https://docs.djangoproject.com/en/dev/topics/auth/#passwords >> >> I think this is the code: >> https://github.com/django/django/blob/master/django/contrib/auth/utils.py >> >> Passwords would be stored like this: >> sha1$a1976$a36cc8cbf81742a8fb52e221aaeab48ed7f58ab4 >> (ie, algo$salt$hash) >> >> The hash algo is stored with the password. This makes it easier to switch >> algos in the future. The salt is also stored with the password which many >> people mistakenly think is unsecure. Also note that the salt is just a >> simple random string and does not have to be particularly long to be >> effective. >> >> If we did implement this approach, the next question is, could we also >> implement a scheme whereby if the algo is changed, when someone goes to >> change their password, the system can confirm that the old password is >> provided correctly and then store the new password under the new scheme? >>
