Yes, I think the salting and hashing we're discussing is meant to protect the passwords once on the server (i.e., if the server/database is compromised). We'd need additional protection to protect them in transit. Another option would be login over SSL, no?
Anthony On Wednesday, September 21, 2011 9:02:07 AM UTC-4, mcm wrote: > > 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? > >> >
