The Scenario:
A web application that once a new user completes the registration, an email will be sent, containing a URL that once tapped from within an iOS device, the iOS app will be launched. This scenario is a classic scenario to make users use the mobile app.
While implementing it (using URL scheme), we start wondering how secured is this method? Theoretically - a malicious app could sign up to the same URL scheme, and according to Apple:
Note: If more than one third-party app registers to handle the same URL scheme, there is currently no process for determining which app will be given that scheme.
Implementing Custom URL Schemes by Apple
In such scenario, if a user is tapping the url inside the email, it is unknown which of the two (or more apps) will be launched - ours or the malicious one. Lets say a different app is being launched - if its really malicious, theoretically it could mimic the login page of our app and grab the user's credentials.
Are there any best practices that handles such scenario? I've read many articles regarding the issue, all of them claims that the only solution is to wait for Apple to make these url schemes unique.
example1,
example2
I would love hearing about any solution to the issue if exist,
Thanks in advance!
We have to assume the malicious app can intercept any data included in this url and that it's author has been free to reverse engineer any behavior included in your app so it can imitate your UI and any validation your app attempts to perform. However we can also assume that the malicious app is contained in its own sandbox so your app can communicate with your backend privately. The malicious app can imitate any such communication but this does allow us to construct a secret unknown to the malicious app. That gives us at least an opportunity to design some countermeasures.
One option might be:
As part of registration construct a public/private key pair and store it in your app.
Send the public key to your web backend as part of the registration process.
Encode they payload of your URL using that public key.
Now we've sent data to your app which might be redirected to a malicious app but which the malicious app cannot read. That's a partial solution. We still need to be careful to design a UI which does not encourage a user to fall for a phishing attack since the URL might still launch the imposter.
The encoded data might be a token we can use to authenticate the user and therefore never require them to re-authenticate within the app. Then there is no login screen to imitate (though a clever forgery might still be enough to trick users into divulging their credentials).
An alternative might be to use a similar per-user secret stored on the client as a salt to combine with the user's password. Their password alone might then be insufficient to authenticate so a malicious app capturing their credentials is not immediately able to access their account.
Another design could be to allow the user to customize their experience in a recognizable way. You might show their selected profile image on the sign in screen. If that selection is known only to your app then an imitator shouldn't be able to duplicate it reliably (again, no guarantee that means users will catch the deception).
All of this introduces tradeoffs; users might still be tricked into revealing information to malicious apps no matter how different they appear from your legitimate client, client side secrets can be extracted by other attacks, and you need a plan to support users who switch, lose, or upgrade devices. You have to decide if any of this actually improves the security of your users and if it is worth the cost to implement.
Try something like this:
In your email, state that clicking on the URL will launch the app and log you in for the first time then prompt user to enter their new password. Include a token in the URL which, when handled by your app, does a one-off login and put the user on a "New Password" page.
If a malicious app has also registered your custom URL and steals the link, they should (hopefully) not be able to do much with it. Even if they replicate your interface and prompt the user for a new password, it's not going to achieve anything.
edit: After thinking on this further, as long as you have an active attacker, you're pretty much screwed. The attacker could continue to emulate your app, effectively MITMing you, regardless of what you do, as long as they're able to hijack that initial URL. My solution would only work in the most basic of cases, not really reliable.
Related
I want to open, from an iOS app, a web page that requires authentication in order to get to that page.
I googled a little bit and I believe I need to use WebKit and Javascript injection, but I am not sure and I have never done something like this, so every bit of information is welcomed or pointing me in the right direction.
I will give an example that I hope will make things more clear(I don't actually want to open facebook, it's just part of the example):
Is it possible to do the following scenario? And if yes, how?
Open a web page from an iOS app, for example: "https://www.facebook.com/profile" without having to go through the login page? I do have the user credentials(username and password), as the user is already logged in with those credentials in the iOS app, but the requirement is to not go through the login page, but to go straight to the profile page.
In general the answer is: no. Even if the user is already logged in and has a valid authentication token that token may only be valid from within your app and not from within the browser. And the login form may be protected by something like a captche preventing you from automatically logging someone in.
There certainly are situation where it is possible: For example if the tokens are not scoped to your app you can try passing them along. Or there is an actual API that you can call with the token that logs the user into the website on the website, etc. But those depend on the specific target website or wether you can control that target website and can add this functionality.
Using this page: https://developers.google.com/identity/sign-in/web/sign-in
It's really easy to add a button to a page for a client side only login with Google.
On Clicking the button, the user is presented with a screen like this:
There are 2 ux_mode for this button: "popup" and "redirect":
https://developers.google.com/identity/sign-in/web/reference
My question is about ux_mode=popup specifically, where the originating page doesn't change, and all the login flow is handled in a separate popup window.
Imagine a good app is published. It seems like an attacker could clone the app, present it to a user. The user thinking it's good app would login and the attacker would have a way to grab a valid token from the user for good app.
Now I understand that in that mode (popup), the IDP (Google) will reject anything that doesn't come from an Origin that is not part of the explicit list of redirect URIs set in the configuration of the project.
But is that the only thing that prevents this? I have read again and again that one should not rely on CORS for the security. Also I'm not sure but it seems that it can be circumvented with a little bit of crafting.
Is there another aspect of the security of this login flow I am missing?
I do not know google implementation but from OAuth 2 point of view:
1/ "The user thinking it's good app" user should check the address bar and a green lock in his browser. It is considered as a users responsibility.
2/ you registered redirect uris which are checked when client is trying to get access token. So google will reject to generate and redirect users browser to malicious app with the token.
3/ browser will reject any communication between popup window and other webpages since they are not same origin. This is called same origin policy and is considered as important security feature of a browser.
In general: app location/uri/origin/domain (as you want) is what identifys your app and security is based on that.
Hope it helped.
I am in the process to design a login for a new app that will be associated with a domain, i.e. be the counterpart to an SPA.
Obviously I want to use
iOS 11 Password Autofill, and
Shared Web Credentials
I have read the documentation on autofill as well as watched the WWDC video about it. Also, I checked the article on Shared Web credentials, which I think is older than the new, reworked autofill. Said article recommends:
Do not use the shared web credentials as your primary storage for secure user credentials. Instead, save the user’s credentials in the keychain, and only use the shared web credentials when you can’t find the login credentials in the keychain.
This strikes me a little odd, because it
- Means I have to cover more possible inconsistencies, i.e. synchronize the keychain somehow wit the shared web credentials (what if I have credentials in the keychain as well as the shared web credentials, but they're different?)
- Potentially leaves "garbage" behind in the keychain if my user user uninstalls my app (naturally I hope they won't ever do this, but let's be realistic, some will)
Especially the last point had always bothered me in the past (before shared web credentials and autofill were a thing, or when my app doesn't have an associated domain). Unlike on macOS, the iOS Accounts & Passwords feature (in the Settings app) doesn't list ALL passwords, but only the ones used by Safari (i.e. the shared web credentials), correct? Keychain Access on macOS instead offers a means to view and manage all credentials, even those that aren't synchronized over iCloud.
I understand why the same is not offered on iOS, but it also means that for those passwords that my app saves (locally) to "its" keychain "part" can only be managed if I offer a UI for this in my app. And if the user uninstalls the app before using this, the item will stay in the keychain, at least it was that way when I tried it a couple of years ago.
My main question now is, wouldn't it be easier to disregard the article's advice and only rely on the shared web credentials for password storage? That's the part they can edit in Settings (if ever need be) and also it will reflect any password changes done on the website. I would design my app like this then:
First launch: App starts on the Login screen and offers the username/password via Autofill
User logs in: App saves a simple flag in the shared user defaults indicating the user is logged in.
App gets relaunched, e.g. after a device reboot: The app skips the login screen due to the flag and gets the password and user name from the shared web credentials (assuming the user previously granted it permission, of course)
User explicitly logs out: The app deletes the flag, basically setting everything back to first launch
User deletes the username and password from the shared web credentials (e.g. in the Settings app or with Keychain Access on macOS): The app falls back to the login screen as soon as it detects this (e.g. when attempting a remote request, or after relaunch), regardless of the flag. I think this matches the user intention best (if you delete a password you don't want some apps to hold onto it until you log them out)
This setup would avoid any issues with different items in the keychain and shared web storage and it would immediately propagate updates done in the webpage to the app as well (which is what I'd intent for my app anyways). Is there anything that would keep this app flow from working?
(Note: I asked the same question on the apple developer forums, so if you see that as well don't be confused. I will update any potential answers from there to here and vice versa.)
Edit to address #Aaron's answer:
Thank you so much for the info. Your answer helped me realize I misunderstood something about shared web credentials: I assumed that for an app with associated domain, you can access the credentials without user interaction (after perhaps an initial authorization). Like you can set the checkbox on macOS when an application requests credentials. I now realize this is wrong and on iOS you would always have to verify with the user, thanks.
For completeness sake, I still want to point out some of the other things you said:
You are right, we will eventually use token based authentication, so I will save that in the keychain (probably in addition to the password, see below). I just tried to keep the question simple enough at first.
Our app is like an email client where you update new incoming "mail". The mentioned "login flag" in something like the user defaults would thus just indicate whether the app should behave as if subscribed to an inbox or not. Like in Mail, you wouldn't expect to have to login even after relaunch.
For this reason I will probably eventually save the user's password in the (local) keychain along with a token. If the token expires, I can request a new one without user interaction, that's important in our general site and app design. Only if that request fails I would use the shared web credentials (updating my local copy of the creds in the process).
For what it's worth, the last point you mentioned is probably debatable. On macOS, for example (where you can edit the entire keychain, not just Safari passwords) de facto logs you out of an app. Mail, again, as an example. If the keychain item for an inbox is gone, Mail re-asks that the next time it is launched and tries to access the content (effectively a "kind of" login in a way).
Again, thank you a lot for answering, now I can close an open todo. :) Also thanks to #HamZa for giving out a bounty!
Considering this advice:
Do not use the shared web credentials as your primary storage for secure user credentials. Instead, save the user’s credentials in the keychain, and only use the shared web credentials when you can’t find the login credentials in the keychain.
The main issue here is that the shared web credentials process is a little clunky — it requires user interaction and takes time to resolve the credentials. So if the user has already authenticated with your app you want to avoid showing them the login page at all. You can do this by storing credentials in your app's keychain where you can access them immediately without a network connection or user permission.
This doesn't mean you need to store the user's password in the keychain. Typically you would store something like an OAuth access token in the keychain. The presence of this token means the user is authenticated - and if an API endpoint rejects your token then you can take them back to the login page.
This suggestion:
User logs in: App saves a simple flag in the shared user defaults indicating the user is logged in.
is possibly insecure depending on what you're hiding behind the login page, but typically any content belonging to the user should require a valid token to access, not just a bool in the user defaults.
I think this matches the user intention best (if you delete a password you don't want some apps to hold onto it until you log them out)
I disagree with this; I would not expect an iOS app to log out because I deleted a password from my Safari keychain.
I'm developing an internal app that will leverage our corporate Google Drive accounts and will be used on shared devices (iPads shared among teachers and students at school sites).
Is there a way to force GIDSignIn to require a password with each sign-in attempt? Right now, even after calling GIDSIgnIn.sharedInstance().signOut() (or GIDSignIn.sharedInstacne().disconnect()) the user doesn't need to enter their password the next time they access the app. That means, when the device is taken by the next user, they could very easily access the other user's account.
Am I missing something? Do I need to somehow clear the cookies store in the UIWebView that the GIDSignIn process uses?
Where available, the GIDSignIn login process uses a SFSafariViewController, not a UIWebView. It leverages the cookies (as well as passwords) stored in Safari, for a quicker login.
I don't think you would be able to clear such cookies. You should be able to force a Google log out, though, by opening https://www.google.com/accounts/Logout in an SFSafariViewController, though the interaction with the rest of your app may be a bit weird. See Logout link with return URL (OAuth) for a way to provide a return URL which you may try to use to control the process (you'll need to use an URL scheme to return, though).
Note that iOS may prompt to save login information, and then provide said login information to subsequent users. You'll need to disable that in Settings -> Safari -> AutoFill
There may be other ways of achieving it via configuration of the device, but iOS is not really designed for multiple users at the moment.
I'm working on a cloud-storage API, authorized via OAuth. Users of third-party applications can permit said application to access their files/data via our RESTful API.
Currently, we are limiting a third-party app access to a users account once. E.g., the Access Token table has a UNIQUE on the consumer column and the user column. This makes sense at first glance, as the user should never be sent to our service to authorize a third-party application twice, since the third-party would already know their user is already tied to our service and wouldn't need to be re-authorized.
However, what if this user has two accounts on the third-party app, and they want said app to connect to their single account on our service twice? This seems likely, given the prevalence of multiple accounts on services such as Reddit.
Here are the possible solutions I've come up with so far, none of them being perfect:
Display an error during the second auth request: This seems like a frustrating experience for the user, a "cop out" of sorts.
Delete the previous token: This would likely annoy the user, as their previous accounts stop working. Even if we display a warning, it would likely be hard to explain what exactly is happening.
Return the same access token as the first request: Each time the access is requested, a set of permissions are also passed along. The permissions for the second request could be different than the permissions for the first request. Also, not sure if this will violate the OAuth spec, as the secondly generated Request Token isn't tied to the Access Token properly.
Allow two to be generated: This would be confusing, as when the user visits their screen full of authorized applications to revoke one, they don't know which authorization is tied to which third-party account. We could ask for an optional third-party username parameter when the Request Token is generated to identify the different auth's (we currently ask for a non-OAuth-standard permission parameter already). But, this seems like it wouldn't be used by 99% of developers and could make application development more confusing.
What is the best way to handle this situation? Is there a standardized practice for handling this use-case?
I think your last case is the right way to go - Allow two to be generated
When the user visits his screen full of authorized application, it's not necessary to show him one and the same Application twice - you just have to delete the tokens associated with the app if the user revokes application access. That is, all his authorizations to the app with all tokens will go away with the revoke, which is fine.