Subject: [OAUTH-WG] Public client cloning

From: Masakazu OHTSUKA <[email-masked]>
Date: Tue, 10 Sep 2019 18:13:15 +0300

Hi,

I've read rfc8252 and have questions about native apps, that I couldn't
find answers on Internet.

Imagine an attacker doing:
1. original app and authorization server conforms to rfc8252 4.1.
Authorization Flow for Native Apps Using the Browser
2. clone the original app, name it malicious app and install on the target
phone
3. remove the original app from the target phone
4. use the malicious app and authorize, OS will invoke malicious app using
custom URL scheme
5. now malicious app has access to the access token

How should we think about this?
What am I missing?

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 10 Sep 2019 10:22:52 -0700

If the phone is compromised, original app replaced by malicious app, then
RFC8252 will not help. The assumption is that the phone is not compromised.

On Tue, Sep 10, 2019 at 9:58 AM Masakazu OHTSUKA <[email-masked]>
wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Filip Skokan <[email-masked]>
Date: Tue, 10 Sep 2019 19:37:50 +0200

A claimed HTTPS URI would tho, right?

Odesláno z iPhonu

10. 9. 2019 v 19:22, Marius Scurtescu <marius.scurtescu=[email-masked]>:

> If the phone is compromised, original app replaced by malicious app, then RFC8252 will not help. The assumption is that the phone is not compromised.
> 
>> On Tue, Sep 10, 2019 at 9:58 AM Masakazu OHTSUKA <[email-masked]> wrote:
>> Hi,
>> 
>> I've read rfc8252 and have questions about native apps, that I couldn't find answers on Internet.
>> 
>> 1. original app and authorization server conforms to rfc8252 4.1.  Authorization Flow for Native Apps Using the Browser
>> 2. clone the original app, name it malicious app and install on the target phone
>> 4. use the malicious app and authorize, OS will invoke malicious app using custom URL scheme

---

From: Masakazu OHTSUKA <[email-masked]>
Date: Tue, 10 Sep 2019 22:27:07 +0300

I see.

Then is this understandable to think from the Authorization Server's point
of view ...

If phone being compromised is a threat that the Client cares,
AS might be interested in NOT supporting public Clients,
and forcing the Client to have a server side, do client authentication, and
have some way to hold a session between the native app and it's server side.

Because if phone is compromised, when AS supports public Clients and
access_token leaks, it's kind of AS's fault (well depending on the
terms...),
but if whatever the means that the phone app and it's server side keeps a
session leaks, it's NOT the AS's fault.

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 11 Sep 2019 09:51:24 +0900

As Filip mentioned, I feel that claimed HTTPS URI would help. Further, if that is used within the dynamic client registration, it could be more secure.

The security assumptions are

1. Phone is not rooted;
2. App Store's vetting of claimed URI is not compromised; etc.

Nat Sakimura
Chairman, OpenID Foundation
https://nat.sakimura.org
2019年9月11日 4:27 +0900、Masakazu OHTSUKA <[email-masked]>のメール:
> I see.
>
> Then is this understandable to think from the Authorization Server's point of view ...
>
> and forcing the Client to have a server side, do client authentication, and have some way to hold a session between the native app and it's server side.
>
> Because if phone is compromised, when AS supports public Clients and access_token leaks, it's kind of AS's fault (well depending on the terms...),
> but if whatever the means that the phone app and it's server side keeps a session leaks, it's NOT the AS's fault.
>
>
> > On Tue, Sep 10, 2019 at 8:23 PM Marius Scurtescu <[email-masked]> wrote:
> > > > On Tue, Sep 10, 2019 at 9:58 AM Masakazu OHTSUKA <[email-masked]> wrote:
> > > > > Hi,
> > > > >

---

From: Masakazu OHTSUKA <[email-masked]>
Date: Wed, 11 Sep 2019 10:26:06 +0300

Okay,
Marius, Filip and Nat, thank you for your answers. :)

On Wed, Sep 11, 2019 at 3:51 AM Nat Sakimura <[email-masked]> wrote:

> As Filip mentioned, I feel that claimed HTTPS URI would help. Further, if
> that is used within the dynamic client registration, it could be more
> secure.
>
> and forcing the Client to have a server side, do client authentication,
> and have some way to hold a session between the native app and it's server
> side.
>
>> On Tue, Sep 10, 2019 at 9:58 AM Masakazu OHTSUKA <[email-masked]
>> <[email-masked]>> wrote:
>>
>>> Hi,
>>>

---

From: Justin Richer <[email-masked]>
Date: Fri, 13 Sep 2019 19:12:47 +0000

If the phone is compromised, it doesn’t matter if the client is public or confidential. In the latter case, an attacker could exfiltrate or capture the client’s own credentials and use them maliciously.

— Justin

On Sep 10, 2019, at 3:27 PM, Masakazu OHTSUKA <[email-masked]<mailto:[email-masked]>> wrote:

I see.

On Tue, Sep 10, 2019 at 8:23 PM Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:
If the phone is compromised, original app replaced by malicious app, then RFC8252 will not help. The assumption is that the phone is not compromised.

On Tue, Sep 10, 2019 at 9:58 AM Masakazu OHTSUKA <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth