Hi Aaron, In usual security senses, just hashing or salting the on-wire passwords will not improve security against credential stealing (both on-wire and local), because stolen hashed password will allow accesses to the resources.
# At least theoretically, we can say that it "weakens" the security, because # stealing hashed passwords is theoretically "easier" than stealing raw # passwords (hint: the latter implies the former). If you are really concerning server-side leakage of on-wire credentials, one way is to request Digest- or APOP-style challenge-responses (but it may need one additional round-trip messages for getting a challenge, depending on the setting.) # One setting on which hashing the password makes security sense is # to use hashed passwords for low-security low-privilege interfaces # (e.g. tweeting) and to require raw passwords for # high-security high-privilege interfaces (such as configuration changes.) On 2010/09/07 12:09, Aaron Parecki wrote: > Hi folks, > > I'm implementing OAuth 2 for my project (geoloqi.com <http://geoloqi.com>) > where > I have some mobile phone clients needing to authenticate. I'm using the > "password" grant type for these clients. Even though the call to the token > endpoint is going over HTTPS, I'm still slightly concerned about sending the > user's password to the server unencrypted. (I don't want the users' passwords > to > appear in my debug log file for instance.) Does the spec allow for or have a > way > to extend so that I can define a hashing algorithm the client can use to > encrypt > the password before sending it? I'm already not storing the passwords in plain > text in the database anyway. Anybody else dealing with a similar issue? > > Aaron > > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth -- 大岩 寛 Yutaka Oiwa 独立行政法人 産業技術総合研究所 情報セキュリティ研究センター ソフトウェアセキュリティ研究チーム <[email protected]>, <[email protected]> OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
