Subject: [OAUTH-WG] Hashing passwords for "password" grant type

From: Aaron Parecki <[email-masked]>
Date: Mon, 6 Sep 2010 20:09:56 -0700

Hi folks,

I'm implementing OAuth 2 for my project (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

---

From: Luke Shepard <[email-masked]>
Date: Tue, 7 Sep 2010 04:46:22 +0000

When a user logs into your website with a login form, do you POST their password in plaintext over HTTPS ? Most websites do, and the security of the "password" grant type is equivalent to that.

If you only allow POST requests to that endpoint, then it should generally keep the password out of most generic access logs.

On Sep 6, 2010, at 8:09 PM, 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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Kris Selden <[email-masked]>
Date: Mon, 6 Sep 2010 22:09:37 -0700

If it is https you aren't sending the password unencrypted. You shouldn't be logging post params unfiltered. You should have a per user random salt you are hashing the password with, which would make it hard for you to hash it on the phone without making a separate call to lookup the salt for that user, which sounds worse than making sure it doesn't get logged.

Phones like the iPhone or Android cannot protect the client secret so using the password type means any client could mimic your trusted client and use the password grant type.

On Sep 6, 2010, at 8:09 PM, Aaron Parecki <[email-masked]> wrote:

> Hi folks,
> 
> I'm implementing OAuth 2 for my project (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
> 
> 
> [email-masked]

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 07 Sep 2010 03:18:47 -0400

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
>
>
> ------------------------------------------------------------------------
>

---

From: Yutaka OIWA <[email-masked]>
Date: Fri, 10 Sep 2010 23:55:17 +0900

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
> 
> 
> 
> 

-- 
大岩 寛   Yutaka Oiwa                       独立行政法人 産業技術総合研究所
            情報セキュリティ研究センター ソフトウェアセキュリティ研究チーム
                                      <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Brian Eaton <[email-masked]>
Date: Fri, 10 Sep 2010 08:49:24 -0700

Hey Aaron -

Here's some more research and recommendations for you:
http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html.

I agree with the other recommendations on this thread, probably not a
good idea for you to invent a hashing scheme for this.  Especially not
if you're going to be accepting logins from browsers.

Cheers,
Brian

---

From: Aaron Parecki <[email-masked]>
Date: Fri, 10 Sep 2010 10:07:08 -0700

Thanks for all the recommendations, everyone. It looks like the best
solution is to just filter out the password from the post data before
logging it.

In my system, only pre-approved clients can use the password grant type,
similar to how Twitter approves access to their XAuth system on a per-client
basis. The only clients that will have access to the password grant type are
mobile phones, never from a web browser. The reason to support passwords at
all is because, frankly, the user experience flow on a phone of opening a
browser after launching the app is not that great. I am also providing
access to the raw headers and post data sent and received from every client
so developers can more easily debug their applications.

Igor - I realize that OAuth is designed to avoid giving out your password to
3rd party clients, which is why I am limiting access to the password grant
type to only "official" mobile clients. Web clients will use the traditional
web auth flow.

Brian - Thanks for the excellent link.

Kris - Can you clarify why phones can't protect the client secret? This
sounds like it would be a major issue for a lot of people.

Thanks again,

Aaron

2010/9/10 Brian Eaton <[email-masked]>

> have a way

---

From: Kris Selden <[email-masked]>
Date: Mon, 13 Sep 2010 00:33:19 -0700

> Kris - Can you clarify why phones can't protect the client secret? This sounds like it would be a major issue for a lot of people.

Mobile apps on phones like iPhone are installed apps, and it is not possible as far as I know to prevent the client secret from being extracted – you have to rely on the user to know if the app they installed is reputable.

Static string constants can be easily extracted, but even if you tried to obfuscate the secret in the compiled code, one could extract the key out with a jail-broken phone using a debugger to capture the secret when it is passed to the API or installing a root certificate to establish a man in the middle to sniff the client secret when it is sent using https. And if you think you can use push notifications to send your app a new client secret, push notifications have been hacked too.

On an installed app, the client id is more of a user agent string, you can use it to try to clue the user into a mismatch between the app they downloaded and the app the website thinks they've downloaded when they are asked to approve.  With the password grant type, it is totally up to the user to know if they can trust the app.  By allowing that grant type in an installed app, you open up the grant type to an unsavory app with a little determination and it would be up to the user to know better not to give their credentials.

For more perspective, please read the following articles (as it relates to mobile apps, client secret, and the password grant type):
http://hueniverse.com/2010/09/all-this-twitter-oauth-security-nonsense/
http://benlog.com/articles/2010/09/02/an-unwarranted-bashing-of-twitters-oauth/
http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars