Re: [OAUTH-WG] Security of OAuth on Andriod [Was: Re: Token Mediating and session Information Backend For Frontend (TMI BFF)]
Karsten Meyer zu Selhausen <karsten.meyerzuselhausen@hackmanit.de> Wed, 17 March 2021 13:20 UTC
Return-Path: <karsten.meyerzuselhausen@hackmanit.de>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9993A08D6 for <oauth@ietfa.amsl.com>; Wed, 17 Mar 2021 06:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hackmanit.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7Zn5FRTa6Uj for <oauth@ietfa.amsl.com>; Wed, 17 Mar 2021 06:20:29 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581633A08C0 for <oauth@ietf.org>; Wed, 17 Mar 2021 06:20:28 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id k8so1797195wrc.3 for <oauth@ietf.org>; Wed, 17 Mar 2021 06:20:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackmanit.de; s=google; h=to:cc:references:from:subject:message-id:date:user-agent :mime-version:in-reply-to; bh=K/zaPzh0T+CvQbdMr+0NdjsWvGYjYuMY8y8sBkZEU0g=; b=U2zDRJiS0rKGhGsouy37HfUG8XAPfrrCMT9Q1U7xCay86uVD5xG+W33S3XR1caxUHw MTvf772h7/xSBw17TwmpIhuEzfUj4RF4wP26iqTXSTGV5orXz3ZWiwTG+bSSkP4t3jOJ i/7k/yepZWQXRwktOBqn7Qxh6FMtnuuvEYOU40QNqiMFYOs/8A/ryHm3CVu2umwDbjGh 6dBaiRHz2OEhGBKrlFnBHo+6PG+rinxJs5JCz6YtuLRvqgS6qZDI/wQMhC+sNjYYyV86 w/dSN/UAxhLkZBCjOwcNoxuTJk26iJ9vdbOpUJNPow1hiPZK07prHlILMrlFkj/6xGam VHMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to; bh=K/zaPzh0T+CvQbdMr+0NdjsWvGYjYuMY8y8sBkZEU0g=; b=Svpl2W5xcbpnYMBp1nq3PTy45WDPImZ1fvx/24JyA5a8zgPMzi7KDnh6q1EK8ec95l 9lBBf1UY/Y7DcQsu+or2ac19cqlHCGS9AiSVYqF+uV+y5dROTnYIxraPZ93ulRhXrIMP mBrCTiP0WkLAJV5jSZxU7fnfrIhJJxRNbuL0KlasdZcrgJlfR1j/oMTFlxmUkIQP5npZ EoI+79c9riCRRIMqrt9DKNLFa8qmbRWqL8HaDdUMonzGFXdQLiz36t/z7nzL3d6bzCw9 q0XW7OzwQIfAzDWJOvnRshg8EgYFbr+jk28bG1V73Kz4bRCCY03OqwJOnfj/7UGGXjNl LP3w==
X-Gm-Message-State: AOAM530u1nLNtuwYCze7dFJUkoRYnAEXbokHIgA+TdIsb+XQG/X0HHK7 kXXM76yMWdyR8B4OKRcKnsIsf6zYg5ve3aSW
X-Google-Smtp-Source: ABdhPJytDYBx3NpT8rGo2UobpmUUeh6E4xtb8AYZKL88xEKuikpM8WKzH2aUlb0v29n3WDD15TF+AA==
X-Received: by 2002:a5d:4443:: with SMTP id x3mr4424466wrr.49.1615987226317; Wed, 17 Mar 2021 06:20:26 -0700 (PDT)
Received: from [10.10.11.6] (b2b-37-24-87-133.unitymedia.biz. [37.24.87.133]) by smtp.gmail.com with ESMTPSA id j13sm25165049wrt.29.2021.03.17.06.20.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Mar 2021 06:20:25 -0700 (PDT)
To: Warren Parad <wparad=40rhosys.ch@dmarc.ietf.org>, Neil Madden <neil.madden@forgerock.com>
Cc: oauth <oauth@ietf.org>
References: <AM0PR09MB2803BF0A50B14B1E2C5F22A4F36A9@AM0PR09MB2803.eurprd09.prod.outlook.com> <F079409D-8D3F-4FE8-A328-A8BE47275238@forgerock.com> <CAJot-L3Dh-uEw8R+QAkhCL_1t=YaRcukqLOjm9EnYj4g8CB-Jg@mail.gmail.com>
From: Karsten Meyer zu Selhausen <karsten.meyerzuselhausen@hackmanit.de>
Message-ID: <b628d66d-b6a3-e405-dcae-ed439440b24c@hackmanit.de>
Date: Wed, 17 Mar 2021 14:20:23 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <CAJot-L3Dh-uEw8R+QAkhCL_1t=YaRcukqLOjm9EnYj4g8CB-Jg@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="hlmwj4EkAnj7ASXJdprZevtpRLvS9CtXE"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/bsZFTEW1hW1ACHVltNB9nkTiBZc>
Subject: Re: [OAUTH-WG] Security of OAuth on Andriod [Was: Re: Token Mediating and session Information Backend For Frontend (TMI BFF)]
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Mar 2021 13:20:33 -0000
I don't think this attack fits into the mix-up attack class. According to the security BCP (section 4.4) mix-up attacks are defined as: > The goal of the attack is to obtain an authorization code or an access > token for an uncompromised authorization server. This is achieved by > *tricking the client into sending those credentials to the compromised > authorization server* (the attacker) instead of using them at the > respective endpoint of the uncompromised authorization/resource server. While the goal of both attacks might be similar, in the scenario we are talking about here there is no honest client who sends credentials to the attacker. On 17.03.2021 11:48, Warren Parad wrote: > Would it be fair to characterize this attack vector as a mix-up attack > where the malicious app is essentially an Attacker AS? > > In the Desktop OS category, responding with the *issuer* in the > authorization response > (https://tools.ietf.org/html/draft-ietf-oauth-iss-auth-resp-00 > <https://tools.ietf.org/html/draft-ietf-oauth-iss-auth-resp-00>) > returned to the user's browser via the one that presumably user > started the flow with. But on Android apps can directly decide > intercept the authorization response thus invalidating the protection > mechanism instituted by the draft? > > I do agree that hypothetically there could be a malicious program > installed in the Desktop OS environment that could perpetrate this > attack. However, without thinking too much about it, I'm biased to > believe existing TLS and browser security mechanisms are sufficient > with the addition of the *issuer *included in the response. > > > > Warren Parad > > Founder, CTO > > Secure your user data with IAM authorization as a service. Implement > Authress <https://authress.io/>. > > > On Wed, Mar 17, 2021 at 9:15 AM Neil Madden <neil.madden@forgerock.com > <mailto:neil.madden@forgerock.com>> wrote: > > Right, but PKCE doesn’t stop an attack when the malicious app > initiates the authorization flow. > >> On 17 Mar 2021, at 08:04, SOMMER, DOMINIK >> <dominik.sommer@milesandmore.com >> <mailto:dominik.sommer@milesandmore.com>> wrote: >> >> >> >> I’d throw in PKCE as a means of assuring that the client who made >> the user follow the auth flow in the first place, is apparently >> the only one able to “redeem” the auth code returned to the >> redirect_uri. >> >> *Von:*OAuth <oauth-bounces@ietf.org >> <mailto:oauth-bounces@ietf.org>> *Im Auftrag von *Om >> *Gesendet:* Mittwoch, 17. März 2021 06:17 >> *An:* Neil Madden <neil.madden@forgerock.com >> <mailto:neil.madden@forgerock.com>> >> *Cc:* Vittorio Bertocci >> <vittorio.bertocci=40auth0.com@dmarc.ietf.org >> <mailto:40auth0.com@dmarc.ietf.org>>; oauth <oauth@ietf.org >> <mailto:oauth@ietf.org>>; Warren Parad >> <wparad=40rhosys.ch@dmarc.ietf.org >> <mailto:40rhosys.ch@dmarc.ietf.org>> >> *Betreff:* Re: [OAUTH-WG] Security of OAuth on Andriod [Was: Re: >> Token Mediating and session Information Backend For Frontend (TMI >> BFF)] >> >> If I read this correctly, >> https://tools.ietf.org/html/draft-ietf-oauth-v2-1-01#section-10 >> <https://tools.ietf.org/html/draft-ietf-oauth-v2-1-01#section-10> >> the 2.1 draft already addresses this under best practices. >> >> On Mon, Mar 15, 2021 at 3:31 PM Neil Madden >> <neil.madden@forgerock.com <mailto:neil.madden@forgerock.com>> wrote: >> >> I want to come back to this topic as a new thread. >> >> As I understand things, the difference on Android is that any >> app can claim to be a generic web browser and so claim to >> handle all URIs. Whereas on iOS only specifically vetted apps >> can claim to be web browsers. Is that correct? >> >> If so, this does seem like a quite large hole in security of >> OAuth on Android. Should we be considering a new draft >> recommending alternative measures (such as attestation) on >> Android? Presumably the same issue is also true on most >> desktop OS? >> >> — Neil >> >> >> >> On 23 Feb 2021, at 15:20, George Fletcher >> <gffletch@aol.com <mailto:gffletch@aol.com>> wrote: >> >> Unfortunately, in the mobile app world this isn't >> sufficient. On iOS using Universal Links will bind the >> https redirect_url to your app in a secure way but it >> doesn't work the same way on Android with App Links. >> There is still a problem with "mobile app impersonation". >> If you have an app that you want to ensure is "your" app >> then the most secure way is to look at "app attestation". >> This is however, way off topic for this thread :) >> >> On 2/14/21 9:28 AM, Neil Madden wrote: >> >> Public clients are implicitly authenticated by their ownership of the registered redirect_uri. This why it’s important to use a redirect_uri for which ownership can be reasonably established, such as HTTPS endpoints with exact URI matching. >> >> >> >> There are more things that can go wrong with that (see the security BCP), but it can be made reasonably secure. >> >> >> >> — Neil >> >> >> >> On 14 Feb 2021, at 13:48, Stoycho Sleptsov<stoycho.sleptsov@gmail.com> <mailto:stoycho.sleptsov@gmail.com> wrote: >> >> >> >> >> >> I would like to add my reasons about the "Why are developers creating BFF for their frontends to communicate with an AS", >> >> with the objective to verify if they are valid. >> >> >> >> I need the client app. to be authenticated at the AS (to determine if it is a first-party app., for example). >> >> If we decide to implement our client as a frontend SPA , then we have no other option except through a BFF, as PKCE does not help for authentication. >> >> >> >> Or is it considered a bad practice to do that? >> >> >> >> Regards, >> >> Stoycho. >> >> >> Sitz der Gesellschaft / Corporate Headquarters: Miles & More >> GmbH, Frankfurt am Main, Registereintragung / Registration: >> Amtsgericht Frankfurt am Main HRB 116409 >> Geschaeftsfuehrung / Management Board: Sebastian Riedle, Dr. >> Oliver Schmitt >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> >> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> >> >> >> ForgeRock values your Privacy >> <https://www.forgerock.com/your-privacy>_______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> >> >> -- >> >> - Regards, >> Omkar Khair >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > > ForgeRock values your Privacy > <https://www.forgerock.com/your-privacy>_______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Karsten Meyer zu Selhausen IT Security Consultant Phone: +49 (0)234 / 54456499 Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training Is your OAuth or OpenID Connect client vulnerable to the severe impacts of mix-up attacks? Learn how to protect your client in our latest blog post on single sign-on: https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks Hackmanit GmbH Universitätsstraße 60 (Exzenterhaus) 44789 Bochum Registergericht: Amtsgericht Bochum, HRB 14896 Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
- Re: [OAUTH-WG] Token Mediating and session Inform… Neil Madden
- Re: [OAUTH-WG] Token Mediating and session Inform… Vittorio Bertocci
- [OAUTH-WG] Token Mediating and session Informatio… Vittorio Bertocci
- Re: [OAUTH-WG] Token Mediating and session Inform… Warren Parad
- Re: [OAUTH-WG] Token Mediating and session Inform… Vittorio Bertocci
- Re: [OAUTH-WG] Token Mediating and session Inform… Stoycho Sleptsov
- Re: [OAUTH-WG] Token Mediating and session Inform… Warren Parad
- Re: [OAUTH-WG] Token Mediating and session Inform… Dominick Baier
- Re: [OAUTH-WG] Token Mediating and session Inform… Warren Parad
- Re: [OAUTH-WG] Token Mediating and session Inform… Vittorio Bertocci
- Re: [OAUTH-WG] Token Mediating and session Inform… Vittorio Bertocci
- Re: [OAUTH-WG] Token Mediating and session Inform… Vittorio Bertocci
- Re: [OAUTH-WG] Token Mediating and session Inform… Vittorio Bertocci
- Re: [OAUTH-WG] Token Mediating and session Inform… Warren Parad
- Re: [OAUTH-WG] Token Mediating and session Inform… Stoycho Sleptsov
- Re: [OAUTH-WG] Token Mediating and session Inform… Warren Parad
- Re: [OAUTH-WG] Token Mediating and session Inform… Stoycho Sleptsov
- Re: [OAUTH-WG] Token Mediating and session Inform… Torsten Lodderstedt
- Re: [OAUTH-WG] Token Mediating and session Inform… Neil Madden
- Re: [OAUTH-WG] Token Mediating and session Inform… Stoycho Sleptsov
- Re: [OAUTH-WG] Token Mediating and session Inform… Warren Parad
- Re: [OAUTH-WG] Token Mediating and session Inform… Stoycho Sleptsov
- Re: [OAUTH-WG] Token Mediating and session Inform… Warren Parad
- Re: [OAUTH-WG] Token Mediating and session Inform… Neil Madden
- Re: [OAUTH-WG] Token Mediating and session Inform… Vittorio Bertocci
- Re: [OAUTH-WG] Token Mediating and session Inform… Vittorio Bertocci
- Re: [OAUTH-WG] Token Mediating and session Inform… Vittorio Bertocci
- Re: [OAUTH-WG] Token Mediating and session Inform… Warren Parad
- Re: [OAUTH-WG] Token Mediating and session Inform… Torsten Lodderstedt
- Re: [OAUTH-WG] Token Mediating and session Inform… Warren Parad
- Re: [OAUTH-WG] Token Mediating and session Inform… Vittorio Bertocci
- Re: [OAUTH-WG] Token Mediating and session Inform… Vittorio Bertocci
- Re: [OAUTH-WG] Token Mediating and session Inform… Warren Parad
- Re: [OAUTH-WG] Token Mediating and session Inform… Vittorio Bertocci
- Re: [OAUTH-WG] Token Mediating and session Inform… Vittorio Bertocci
- Re: [OAUTH-WG] Token Mediating and session Inform… Philippe De Ryck
- Re: [OAUTH-WG] Token Mediating and session Inform… Vittorio Bertocci
- Re: [OAUTH-WG] Token Mediating and session Inform… Philippe De Ryck
- Re: [OAUTH-WG] Token Mediating and session Inform… Neil Madden
- Re: [OAUTH-WG] Token Mediating and session Inform… Philippe De Ryck
- Re: [OAUTH-WG] Token Mediating and session Inform… Neil Madden
- Re: [OAUTH-WG] Token Mediating and session Inform… Warren Parad
- Re: [OAUTH-WG] Token Mediating and session Inform… Philippe De Ryck
- Re: [OAUTH-WG] Token Mediating and session Inform… Neil Madden
- Re: [OAUTH-WG] Token Mediating and session Inform… Stoycho Sleptsov
- Re: [OAUTH-WG] Token Mediating and session Inform… Torsten Lodderstedt
- Re: [OAUTH-WG] Token Mediating and session Inform… Brian Campbell
- Re: [OAUTH-WG] Token Mediating and session Inform… Dominick Baier
- Re: [OAUTH-WG] Token Mediating and session Inform… Vittorio Bertocci
- Re: [OAUTH-WG] Token Mediating and session Inform… Hans Zandbelt
- Re: [OAUTH-WG] Token Mediating and session Inform… Dominick Baier
- Re: [OAUTH-WG] Token Mediating and session Inform… Warren Parad
- Re: [OAUTH-WG] Token Mediating and session Inform… Dominick Baier
- Re: [OAUTH-WG] Token Mediating and session Inform… Warren Parad
- Re: [OAUTH-WG] Token Mediating and session Inform… Neil Madden
- Re: [OAUTH-WG] Token Mediating and session Inform… Brian Campbell
- Re: [OAUTH-WG] Token Mediating and session Inform… Dominick Baier
- Re: [OAUTH-WG] Token Mediating and session Inform… Neil Madden
- Re: [OAUTH-WG] Token Mediating and session Inform… Philippe De Ryck
- Re: [OAUTH-WG] Token Mediating and session Inform… Neil Madden
- Re: [OAUTH-WG] Token Mediating and session Inform… Brian Campbell
- Re: [OAUTH-WG] Token Mediating and session Inform… Neil Madden
- Re: [OAUTH-WG] Token Mediating and session Inform… George Fletcher
- Re: [OAUTH-WG] Token Mediating and session Inform… Neil Madden
- [OAUTH-WG] Security of OAuth on Andriod [Was: Re:… Neil Madden
- Re: [OAUTH-WG] Security of OAuth on Andriod [Was:… Om
- Re: [OAUTH-WG] Security of OAuth on Andriod [Was:… Neil Madden
- Re: [OAUTH-WG] Security of OAuth on Andriod [Was:… SOMMER, DOMINIK
- Re: [OAUTH-WG] Security of OAuth on Andriod [Was:… Neil Madden
- Re: [OAUTH-WG] Security of OAuth on Andriod [Was:… Warren Parad
- Re: [OAUTH-WG] Security of OAuth on Andriod [Was:… Karsten Meyer zu Selhausen
- Re: [OAUTH-WG] Security of OAuth on Andriod [Was:… Aaron Parecki
- Re: [OAUTH-WG] Token Mediating and session Inform… Brian Campbell
- Re: [OAUTH-WG] Token Mediating and session Inform… Neil Madden