26

I've noticed a trend in mobile and desktop apps in recent years with the advent of OAuth (and it may also affect other frameworks) to request a user to sign up or log in using 3rd party authentication providers, usually social accounts like Twitter, Facebook or Google. The problem comes when I can't trust the app I'm entering the credentials in, because the developer has embedded a browser in a dialog/window owned by the app, and I have no way to know if the page I'm seeing is a legitimate login page, or that the user agent (browser and layers on top) can be trusted.

I'm not talking about apps from small indie devs either, I'm talking software by widely trusted companies (at least in the software development community where I spend most of my time). Some examples that I've seen in the last few weeks:

  • Atlassian Sourcetree allows you to log in using your Google account - in an Atlassian window
  • Postman Google login occurs in a Postman window
  • Microsoft Visual Studio and Office do it with your Microsoft Account (granted, this is trusted a bit more as the app is owned by the auth provider, but it still endorses the process)
  • Some apps ask you to, for example, log into Paypal in a browser window inside their app

Similar questions asked in the past regarding mobile apps (but the problem is not limited to mobile):

One question related to a desktop app:

And tangentially related is the use of iframes in web applications:

This is an issue of trust for me when moving from app space to the web to authenticate, get a token and return back to the app. I might trust the companies enough to install their software, but not enough to enter the master keys to my Google account (for all intents and purposes) into their software.

In researching this question further I found this IETF draft which states:

Embedded user-agents are an alternative method for authorization native apps. They are however unsafe for use by third-parties to the authorization server by definition, as the app that hosts the embedded user-agent can access the user's full authentication credential, not just the OAuth authorization grant that was intended for the app.

EDIT: The draft above became RFC8252, dated October 2017, thanks to @Geir for directing me to that.

and an older directive, RFC6749 (dated October 2012) which also mentions among other interesting tidbits:

An embedded user-agent poses a security challenge because resource owners are authenticating in an unidentified window without access to the visual protections found in most external user-agents. An embedded user-agent educates end-users to trust unidentified requests for authentication (making phishing attacks easier to execute).

My questions:

  1. Am I right to be concerned that this is a growing opportunity for phishing and MITM attacks (fake or hijacked browser in the middle which steals credentials and/or tokens in real time, also defeating 2FA)? Not so much that trusted software itself is likely to be made malicious, but that widespread usage discourages users from verifying end-to-end trust, condoning (even encouraging) users to blindly enter credentials into any app that asks for them?

    I think the last section quoted above answers undeniably in the affirmative, but I'm interested in further comments and perspective around this, particularly as a software developer myself.

  2. The obvious "correct" way to do it is to forward the user to their trusted browser for authentication instead, however this can be a poor user experience, and doesn't actually fix the problem (a malicious developer could open a window from the main app that looks like Chrome, but isn't - the fact user sessions from the main browser window are not preserved, among other visual cues would probably go unnoticed by most).

    Is there a better way to design the user experience of apps such that a user can be sure they are using a trusted software stack (app and rendering engine), in-app? Should there be device- or system-level handling of such auth requests in a way that's hard to mimic?

  3. I'm not really involved in the security scene, just a lurker here, is this a well known concern in the industry? Are there efforts to curb this sort of authentication flow?

Community
  • 1
pcdev
  • 311
  • 3
  • 10
  • 1
    An interesting link from a comment in one of the linked questions: https://medium.com/@rrridges/when-security-conflicts-with-ux-who-wins-70ff0402991e - imo security should *always win*, but UX needs to then craft acceptable security practices into a user friendly solution, even if other entities (eg. OS vendor, hardware designers) need to get involved. – pcdev Feb 14 '18 at 04:00
  • just use a password manager, it won't auto-fill phish pharm logins. – dandavis Feb 14 '18 at 21:28
  • Thanks @dandavis, I do use a password manager, but that's not the point. First, I'm talking in general terms rather than my specific case and the vast majority of internet users don't use a password manager (another problem altogether). Second, I'm not so concerned about specific apps or even phishing as a whole, I'm more concerned about the trend towards unverifiable authentication stacks and specifically the behavioural change it encourages. (continued...) – pcdev Feb 14 '18 at 21:57
  • Besides, using a password manager doesn't fix anything I've described: either it autofills into an embedded (say IE) browser control or it doesn't. If it does then the credentials could be compromised by the host app, and if it doesn't then we're back to square one: the user has to enter the password manually on all such apps that ask for social logins (nullifying the benefits of a pw manager), and by extension users on the whole are trained to think that's acceptable. The issue is embedded user agents, not password handling per se. – pcdev Feb 14 '18 at 22:02
  • 1
    the host can't get auto-filled credentials. not auto-filling is a huge red flag to anyone who has signed into say, google before, thus identifying suspicious logins and preventing the very attack you describe. – dandavis Feb 14 '18 at 22:46
  • 1
    Again, beside the point. The host can get whatever it likes from embedded browser controls, it owns them. Not auto-filling might be a red flag for you and I and others who proficiently use password managers (a tiny fraction of a percent of internet users, I'd guess), but it doesn't help the fact that users are being actively encouraged in many apps by many big name vendors to enter credentials into potentially untrustworthy windows - companies who should be encouraging better login habits. My questions: Is this simply not a concern to others? How can we as an industry do better? – pcdev Feb 15 '18 at 00:50

3 Answers3

10

  1. Am I right to be concerned that this is a growing opportunity for phishing and MITM attacks (fake or hijacked browser in the middle which steals credentials and/or tokens in real time, also defeating 2FA)? Not so much that trusted software itself is likely to be made malicious, but in that widespread usage discourages users from verifying end-to-end trust, rather that blindly entering credentials into any app that asks for them?

    You are correct 100%. In the end, most users expect websites to be similar. If every website has a green padlock, users notice big red security warnings. When every single website asks for users' email, etc, users start handing out their contact info without a second thought.

    Similarly, users will be "desensitized" when more and more apps ask for credentials using a in-app browser. Hopefully this won't lead to users eventually sharing credentials across services without blinking but in the worst-case scenario it may.

  2. The obvious "correct" way to do it is to forward the user to their trusted browser for authentication instead, however this can be a poor user experience

    Both of these statements are correct.

    and doesn't actually fix the problem (a malicious developer could open a window from the main app that looks like Chrome, but isn't - the fact user sessions from the main browser window are not preserved, among other visual cues would probably go unnoticed by most).

    Sadly also true, although at this point it is, for the most part, plain-old phishing. The malicious might as well send the user to a phising website, too :/

  3. Is there a better way to design the user experience of apps such that a user can be sure they are using a trusted software stack (app and rendering engine), in-app?

    I don't think so, sadly.

    Should there be device- or system-level handling of such auth requests in a way that's hard to mimic?

    This is extremely interesting. A related question on SE discusses this issue when it comes to system-level login prompts. The gist of it is that a current implementation/solution-in-use does not exist, but some interesting ideas include shortcuts/buttons that close windows that are not owned by the system. That way, the system could say "press XYZ to continue" and unless it really is the system the window gets closed and the credentials are not sent.

    In this specific case, the OS could have a system browser instance with similar features as mentioned above. This browser could be a one-page, no-hyperlink-browsing, just-for-login HTML/css/js renderer/parser with an easy api for OAuth.

    I'm not really involved in the security scene, just a lurker here, is this a well known concern in the industry?

    The concern of phishing is (or at least should be) always a concern, but this is the first time I have, personally, thought of it in the context of OAuth, et al.

    Are there efforts to curb this sort of authentication flow?

    I am not aware of any efforts to protect against this attack, but u2f hardware smartcards such as yubikeys encrypt 2fa tokens to the specific website with which they are setup. This protects against phishing, but still doesn't keep a malicious/fake browser from stealing the username, password, etc. In addition, a malicious (in-app) browser could just steal session cookies once the user is logged in.

Proposed solution for applications developers

OAuth should be done through the user's default browser, not in-app.

Possible solution for OS developers

As discussed above, the OS could theoretically provide trusted input methods for OAuth, etc. This could also extend past OAuth to allow users to easily and securely log into services like git in cli's, etc.

user196499
  • 1,121
  • 7
  • 11
  • Great answer, thanks for contributing! I'm especially interested in the SSE link you provided about login prompts. Another question that had always been in the back of my mind. I really hope more happens in this area. That was another thought I had was that the eventual demise of passwords altogether might go a way to solving this particular issue, although no doubt it will just replace the issue with a different one... – pcdev Feb 24 '18 at 11:13
7

It is a concern, albeit (I believe) one that is only now becoming widely recignized. For instance, RFC 8252 states about OAuth2 that:

OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. (https://www.rfc-editor.org/rfc/rfc8252).

Community
  • 1
Geir Emblemsvag
  • 1,599
  • 1
  • 11
  • 14
  • 2
    Interesting, I hadn't followed the links through to RFC 8252, thanks. However this doesn't really answer my questions, sorry. And while RFC 8252 is relatively new the problem has obviously been known about since 2012 when RFC 6749 was finalised. Do I, a lowly moonlighting security wannabe, approach Microsoft, Atlassian and others and say "Oi, you're doin' it all wrong"? I'll almost certainly be ignored. Any better suggestions? – pcdev Feb 22 '18 at 04:47
  • 1
    True, I sort of glossed over part 2 of your post. Personally I believe (or rather, hope), that this problem would be reduced once most applications use the device's native browser. Then users would get used to a certain look and feel of the login process. A malicious app trying to fake that process by "pretending to open Safari" would almost certainly get one aspect wrong, and throw of the user. If we can train users to don't enter passwords when they feel suspicious, we have gained a lot of security. – Geir Emblemsvag Feb 22 '18 at 07:22
1

Not a full answer, but I want to add that U2F makes authentication from the browser nearly unphishable. If that were to be used, your "correct" strategy actually becomes a secure strategy. With U2F, users don't enter passwords into their browser. Instead there's a secure handshake between the browser and the U2F authenticator (protocol summary). The biggest problem with U2F is that businesses don't feel motivated to invest in the option.

Neil Smithline
  • 14,702
  • 4
  • 38
  • 55
  • Thanks for the link, I hadn't looked into that much before. Yes I definitely like the idea of passwordless authentication and I'm a fan of 2FA but I think the best security still involves something you have and something you know, and for the time being (at least, perhaps, until neural interfaces are mature enough), that involves entering that "something you know" into some (hopefully) trustworthy and secure authentication chain. Interestingly, all passwordless auth schemes I've seen reduce that security to simply "something you have": mobile phone, OTP, a fingerprint, etc. etc. (continued...) – pcdev Feb 26 '18 at 00:47
  • I think that this is better than the current situation where insecure passwords are rife, but I don't actually think totally passwordless is the way to go either. Another discussion for another question, perhaps :) – pcdev Feb 26 '18 at 00:49
  • great point, but sadly u2f does not protect against an evil in-app browser that steals session cookies :/ (mostly mumbling to myself here) – user196499 Feb 26 '18 at 02:54
  • @user196499 - I suspect that identity providers could protect against in-app authentication by either refusing to allow login there. But it just doesn't seem that there's sufficient user demand. It makes me sad too :( – Neil Smithline Feb 26 '18 at 14:45
  • @pcdev - I don't think that U2F requires it to be passwordless. Besides the authentication that takes place on the U2F authenticator app/device to allow you to get it to work, you can still use a password for authentication. FIDO (the org managing U2F) suggests that you can make your password as simple as a 4-digit PIN, but that's up to you. – Neil Smithline Feb 26 '18 at 14:47
  • @Neil right, in fact the page you linked to actually uses examples with passwords. My point was not about U2F per se, but just that passwordless auth schemes all seem to eliminate the "thing you know" part which ultimately reduces security. Adding at least a PIN is definitely worth the extra effort. – pcdev Feb 26 '18 at 21:51