Doing as in the article above, if x compromises the server x can login since the hashed password *are the secret* . To do things right the hash of a secret arriving from the client must be computed every time on the server before comparison.
SSL hides the secret so it's a good choice. mic 2011/9/21 Anthony <[email protected]>: > 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? >> >> >
