search

Yubico / yubikit-ios

Yubico Mobile iOS SDK - YubiKit
Apache License 2.0
198 stars 44 forks source link

Multi-Facet apps #49

Closed bugnuker closed 3 years ago

bugnuker commented 4 years ago

Hello,

When working with this SDK, we are not seeing a appId or facet check on a multi-facet setup.

In the demos, the appId that is used it "https://demo.yubico.com" - an example of a single facet app.

In this link here: https://developers.yubico.com/U2F/App_ID.html - it is explained about multi-facet apps and the app-id.json file that gets associated with either Android or iOS apps, etc.

We do not see the SDK honoring this multi-facet setup. It does not appear to retrieve the app-id.json file. Maybe I am wrong and doing something incorrectly.

Can you please explain how we should correctly call the SDK with a multi-facet app, with the correct ios:bundle-id: entry in the json file being consumed?

Thanks!

jensutbult commented 4 years ago

The SDK does not implement any network requests and can not fetch the app-id.json file. If you need to do that you'll have to implement that yourself. Worth noting is that in the SDK appId is used as origin.

Can you provide more information about the problems you're trying to solve?

bugnuker commented 4 years ago

I am trying to find best practices on how to implement with multi-facet. Right now, the SDK will take any value you pass to it for the appID. There is nothing checking the validity of that.

For example, if you take the Yubico example, with the AppID = "https://demo.yubico.com" - anyone can make an app using that AppID with this SDK. And that app will happily sign messages for keyHandles generated outside of that app. This can allow a copy-cat app to be created that wont validate the app info correctly.

Android has built in support via the OS, and this info is validated so an app can't be created to abuse the appID/origin.

On one side, I understand the SDK is not making network requests. On the other side, from what I understand, this allows anyone to spoof an app with this SDK as it will not validate the app settings. It enables an attacker to use this SDK, input any orgin/appID they wish (copy it from a valid app-id.json file) and nothing validates it. The user would have no idea they have just used a malicious app, but the message was signed anyway.

It would seem we need iOS to build this into the OS for it to be secure.

Please do correct me where I am wrong.

Thanks

dainnilsson commented 4 years ago

Yeah, I think you've got it correct. The client-side validation of AppId really only makes sense if the FIDO client is separated from the app, is trusted, and is the only mechanism for accessing credentials (eg. provided by the OS). Using the SDK, your app acts as the FIDO client, and is assumed to be trusted.

bugnuker commented 4 years ago

Anyone know if iOS 14 includes any native support for FIDO for apps? Is it on a roadmap?

dainnilsson commented 4 years ago

I have no insight there, but can point out that native apps can use the sfsafariviewcontroller to access the platforms FIDO functionality, if that helps.