Let’s say there is a mobile app called Authentic App that uses Blockstack sign in and stores data in Gaia buckets for its users.
Currently, Blockstack authentication on mobile is handled through a publicly accessible redirect endpoint on the web for the app. Let’s call is redirect.html. To make this work, the mobile app has a custom protocol handler that is unique to the app. On iOS, this is done through adding URL types on the app’s Info Page which involves specifying unique Identifier and URL Schemes . This make it possible for the app’s web-based authentication redirect.html endpoint to redirect the user back to the mobile app.
Let’s assume that redirect.html for Authentic App is hosted at www.authentic.com/redirect.html
This means that anyone who knows the strings used as Identifier and URL Schemes on the mobile app can create an app, let’s call it Fake, where users can login and use the Gaia buckets for the app www.authentic.com, thereby impersonating Authentic App. Fake can then decrypt any useful files that the users might have encrypted while using the authentic app, or can delete any useful information that the user will have created using the authentic app.
One could argue that we can randomize the name of the redirect endpoint to something like www.authentic.com/vErYRaNdOmAnDlOnGnAMe.html using a random string generator of some sort, and then make it harder for an adversary to know the name or the URL string. I don’t think this will work since the adversary can figure out the name using the URLs of traffic going in and out of the app during Blockstack Authentication.
Another line of defense we have is that the Identifier and URL Schemes are part of the compiled code given to users of the app and hence it is harder for anyone to know them. I am not sure how true that is since I am novice to this. However, I believe that a highly motivated and financed adversary has good enough tools, time and other resources to “de-compile” the code and get attributes like Identifier and URL Schemes since these are names used to identify the app in the phone, hence they should be somewhere accessible. Also, the URL Schemes is also hardcoded on www.authentic.com/redirect.html which is a publicly accessible file.
Given the nature of the applications being built on Blockstack, and Afari in particular, it makes sense to believe that we will have enough targets on our back for people trying to “break” the application.
I can’t think of ways to fix this — let me know what you guys think. I have also opened an issue on the iOS repo to make sure that we do not forget about it.