[Openid-specs-native-apps] Identifying applications.

[William Denniss]

I think we can rely on the OS-level assertions to a certain extent – Bundle
ID on iOS, Package Name + Signature on Android.  Google does this today in
its OAuth for Installed Applications implementation.

John's point about an attacker potentially being able to upload an app with
a bundle-id matching an enterprise app to the App store is valid. To
counter that, it may be recommended for the enterprise to create a normal
Developer Account (~$100/yr) just to register the bundle ID (enterprise
accounts don't have this functionality it seems
<http://stackoverflow.com/a/8879763/72176>).  In general I'd say it's
fairly safe even without doing that – for the attack to work, you'd have to
get through Apple's review process, and still convince the user to download
& use the app.

William


On Fri, Aug 8, 2014 at 6:24 AM, Mike Varley <mike.varley at securekey.com>
wrote:

>  Verifying an App identity on any given mobile platform seems to be a
> challenge - should the spec define its own mechanism for verifying an App
> identity? or is that too much scope creep?
>
>  (something like the proof-of-possession spec for OAuth 2.0…)
>
>  MV
>
>
>
>  On Aug 7, 2014, at 2:46 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>
>
>  Hi William,
>
>
>  Thanks that is useful information.
>
>  My concern is that a large user of this may be enterprises.
> A enterprise creating app x for there enterprise store might be subverted
> by a app in a public store.
>
>  I can see an attacker sending a email link to an employee at company x
> saying down load this one time free app, that impersonates the app name of
> some internal HR or finance application.
>
>  It will at minimum need to be a security consideration, I think.
>
>
>  Regards
> John B.
>
>   On Aug 6, 2014, at 8:58 PM, William Denniss <wdenniss at google.com> wrote:
>
>  On Wed, Aug 6, 2014 at 4:15 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>
>
>> Can people comment on what needs to be passed to uniquely identify an app
>> on iOS , Android and Windows mobile.
>>
>
>  For iOS it is the bundle identifier. These are globally unique within the
> Apple ecosystem.  I verified this by attempting to create a new app using a
> known bundle identifier of another app, and got the error: "The Bundle ID
> you entered has already been used.".
>
>  The bundle identifier is passed by the OS during inter-app communication
> in the
> UIApplicationDelegate/application:openURL:sourceApplication:annotation:
> <https://developer.apple.com/library/ios/documentation/uikit/reference/UIApplicationDelegate_Protocol/Reference/Reference.html#//apple_ref/occ/intfm/UIApplicationDelegate/application:openURL:sourceApplication:annotation:>
> method which can be used to restrict which apps you interact with. This has
> applications similar to whitelisting javascript origins and redirect URIs.
>
>  On Android, the package name – very similar in concept to the iOS bundle
> identifier – is also globally unique (docs
> <http://developer.android.com/guide/topics/manifest/manifest-element.html#package>).
> Two apps on the Play Store cannot have the same package name.
>
>  As Android allows apps from unknown sources, the OS level assertion of
> the bundle identifier is less authoritative than on iOS, which is why it
> may be advisable to also verify the application signature. It is
> theoretically possible to distribute an iOS app with a conflicting bundle
> identifier, but it would have to be distributed outside the App Store which
> is hard (Enterprise, AdHoc or development builds – none which can achieve
> wide distribution).
>
>  William
>
>
>
>  _______________________________________________
> Openid-specs-native-apps mailing list
> Openid-specs-native-apps at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps
>
>
>
> _______________________________________________
> Openid-specs-native-apps mailing list
> Openid-specs-native-apps at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20140808/02c07fb2/attachment.html>