Re: RFC 8252 is a complete joke

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Unfortunately I don't think it is remotely possible to educate the general public enough about Oauth and why using a browser to authenticate is important. The RFC even recommends "in app browsers", which are not secure at all. I mean after all, TikTok was previously injecting JS into websites via their website to log keystrokes "for debugging purposes" (Ref: https://www.macrumors.com/2022/08/18/felix-krause-in-app-browser-javascript-tool/)

People are trusting in general, and Oauth via a native app looks natural enough, that it is trivial to phish credentials in such a manner. In fact there are quite convincing Steam phishing attacks that seem to be prompting for Oauth, but they actually just generate a "browser  window" in the fake website via pure CSS/JS. 

Anyway, I don't think an RFC can really solve it, since Oauth 2.0 is already everywhere.

- Raghu Saxena

________________________________________
From: ietf <ietf-bounces@xxxxxxxx> on behalf of Michael Thomas <mike@xxxxxxxx>
Sent: Wednesday, June 21, 2023 2:53 AM
To: IETF Discussion Mailing List
Subject: RFC 8252 is a complete joke


About 10 years ago I discovered that IETF was working on OAUTH as a
replacement for sites to need user credentials to do things on their
users' behalf, typically for use to post stuff to social media sites at
the time, but also as a convenient general login mechanism. I had a
native app I wrote and I didn't like having to store use credentials so
that seemed great. However when I thought about it it seemed there was
nothing to prevent me to still get the login credentials from the user
of my app. Native apps, like phone apps, have complete control of the UI
unlike a web browser which can be assumed to be a neutral player from
the user's standpoint. When an app asks you for your login credentials
for, say, Facebook you have to make a decision whether you trust the app
or not. With OAUTH it makes it seem like it's safe regardless whether
you trust the app or not.

It isn't. Since the app has complete control of the UI unlike a browser,
it completely controls what the user sees. There is an infinite number
of ways for a native app to game the user to get their credentials while
still completing the OAUTH transaction on the user's behalf. I brought
this up to the OAUTH wg at the time and was roundly flamed by the
working group and especially the lead author at the time (who it seems
flamed out later for seemingly unrelated reasons). The end result was a
little line or two blurb in the security considerations and the end
result is, as I predicted, that nobody would care about OAUTH use in
native apps and it would become commonplace.

Later I heard that the OAUTH wg had created RFC 8252 which at first I
thought was vindication after the hostility I was shown by the wg. I was
looking it up again today though and found out that instead of just
being an information "don't do this" it is in fact a BCP. The jist is
that native apps should use browsers to do the login. This is tantamount
to asking foxes to be nice while guarding the hen house. Or closer to
home, that RFC 3514 and the evil bit should be employed. Native apps
intent on stealing your credentials can still steal your credentials no
matter what RFC 8252 says and the user will be none the wiser.

What should be the BCP is that OAUTH should *never* be used for native
apps and that users should *always* be cognizant that an evil app can
steal their credentials just like when I specifically had to store them
for my app to do stuff on their behalf. How on earth did the IESG let
this get through? I mean seriously, this is a complete joke. Asking
people to not be evil is not security and is certainly not a best common
practice. This RFC should either be declared historic or rewritten.

Mike






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux