Aaron,
Actually, I never fully understood the "password" access grant type, as
technically it is against the very spirit of OAuth, which, I thought,
was to avoid divulging the password.
TLS provides confidentiality, and so you ought to be able to rely on
TLS, although I have no idea what kinds of logs there may be.
Unfortunately, hashing won't help with encryption, because it is
impossible to decrypt. Relying on the hash of the password, without
salt, is not solving the problem because anyone who can intercept this
hash could then use it. Things would be somewhat better if the salt were
known, but how can the salt be known to anyone except the server that
has created it (and must keep it secret)? I guess the only sure way is
to use the public key of the receiver (or a one-time pad based on the
shared secret).
Igor
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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
