We published a new security best practice that explains the caveats when integrating II on mobile applications. A short presentation which is part of the November global R&D covers this best practice as well.
This is a rather complex best practice where understanding the problem requires knowledge of mobile inter-app communication and II internals. The implementation isn’t straightforward and requires multiple security controls to be implemented diligently. We’ve noticed many great questions popped up during the global R&D. Therefor, we wanted to create this post to gather any questions or feedback related to securely integrating II on mobile apps.
Thank you Roel and team for the new best practices and the GR&D presentation. I am very interested in using II in mobile apps or similar scenarios. And this solution is very clever.
I am wondering if there is a small risk that the malicious app can “spoof” the browser. Say for example the user has installed Safari and Chrome and is using II with Safari only. Then say the malicious app redirects to Chrome and tells the user that it “only works with Chrome currently and that Safari support is coming in the near future”. With such a benign sounding message it could convince the user that it is necessary that he adds Chrome as a device to his II. It is conceivable that the user never was against adding Chrome to his II but he simply didn’t have a reason before to do so. Now is the first time he sees a reason to add Chrome, and he simply does it. But the malicious app doesn’t actually open the external Chrome browser. Instead it opens a modified embedded browser that looks like Chrome. Most users will not notice the difference. Now the II authentication is carried out in an untrusted browser and anything can happen that the attacker wants.
So to understand correctly, the native app shows a malicious embedded webview instead of opening the browser installed by the user. Then the user authenticates with II, and then the malicious app has access to the user’s II by registering another credential without the user’s knowledge.
Embedded webviews are scoped to the native app, which means they only have access to the passkeys of the domain that has been tied to the native app, not the passkeys that are needed to access the user’s II. Also they don’t have access to the stored list of previously used II numbers since that’s stored separately in each individual browser the user uses.
So this attack would require the user to re-enter their II number and then also enter their secret phrase to access their II since that is the only authentication method not tied to the origin.
At this point I’d expect most users to be highly suspicious: “why do I suddenly have to go through the recovery flow?”. So such an attack would not be a unnoticeable attack, most users, likely one of the first users would already bring it up.
Installing a full fledged malicious browser might be a higher risk to a user, since that (probably?) has access to all passkeys. But a malicious browser like that won’t be available for long on most app stores, if it even gets past review in the first place
I meant that the user is made to add Chrome as a new device to his II. I mean by the normal flow of adding a device which is by scanning a QR code and confirming on the existing device. Not by entering the recovery phrase. As a result, a new passkey, to which the malicious app has access, is added to the II. Adding a device is quite a normal flow and not suspicious to everyone (though maybe to you and me in this situation it would be). The user may have already thought about adding Chrome to his II but never got around to doing it. Doing it now may seem like a good idea.
This new device flow by QR technically doesn’t even require a webview. One non malicious example I remember was Astrox ME wallet using this new device flow to access NNS functionality directly from the wallet itself. In this particular example, the user is clearly informed that they’re adding the wallet itself as device to their identity.
So yes this flow could be misused with some social engineering (convincing users to do certain steps).
Not sure how many clear warnings these screens show to warn and inform users of what they’re doing, this could possibly be improved if the warnings are currently not clear enough.
Overall, most II users probably would notice something is different if they’re suddenly in the register device flow and asked to open II on another device/browser
Edit:
After re-reading your post a few more times, I think I understand the exact flow you mention better:
the user sees II inside the webview after pressing sign in in the dapp
thinks he’s (for some reason) in a browser that he doesn’t normally use (webview is styled to look like a legitimate browser)
uses the new device flow since he didn’t use this browser before
malicious app now has access to the user’s II
In this example, the webview isn’t even needed, all you need is to visually render something to convince the user to enter their II number and go to II on another device and approve.
This is a common issue with malware on any platform once a user installs untrusted software, either directly or bundled with legitimate looking software.
There’s a lot of malicious things software can do, one example mentioned here is impersonating legitimate software to steal credentials.
One non malicious example I remember was Astrox ME wallet using this new device flow to access NNS functionality directly from the wallet itself.
We’ve asked them to remove this feature since this is teaching users that adding passkey supplied by someone else is acceptable which increases the likelihood of phishing attack. I believe they added some warning about this risk now.
At some point, phishing attacks can only be prevented by a cautious user. We need to create the best technical solution that makes a phishing attack clearer to the victim but eventually if a user is willing to go along with arbitrary actions we are unable to prevent a compromise.
Great suggestions! I’ll take these ideas into account when we’re working on this screen
I did not open this page by following a link
Technically, we can prevent this from being possible by not having a url for this screen, not sure if this is currently already the case, but if not we should avoid making pages like these to be directly reachable by url instead of user interaction.