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

[Aaron Parecki <[e-mail]>]

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 <[e-mail]>

> 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
>
> On Fri, Sep 10, 2010 at 7:55 AM, Yutaka OIWA <[e-mail]> wrote:
> > 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> > --
> > 大岩 寛   Yutaka Oiwa                       独立行政法人 産業技術総合研究所
> >            情報セキュリティ研究センター ソフトウェアセキュリティ研究チーム
> >                                      <[e-mail]>, <
> [e-mail]>
> > OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405
> 46B5]
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>