53

A lot of services, sites, and applications offer the 'login with Facebook' or 'login with Google' option. For many sites, the browser opens a separate window in which you can enter your username and password. This way, you can check the URL and convince yourself that the origin really is Google/Facebook/whatever. Logging in in this window should be safe, and there is no reason to worry (apart from any privacy concerns you might have).

However, this is not always the case. Though I can not find them now, I am quite sure that there are some sites which require you to login with your Facebook/Google account on their site (so the URL shown is not Facebook/Google). I am sure there are some desktop application which do this as well. One example I can give is Nvidia's GeForce experience. Apart from the ridiculousness of having to sign in on Google or Facebook to update a driver, this does not seem to be good practice, since I can't check if I actually login on Google or that the login window is spoofed.

Enter image description here

I have read a couple of times that using other services to login is considered good practice. Is this true? I can see some serious problems with it.

Peter Mortensen
  • 885
  • 5
  • 10
Ruben
  • 592
  • 1
  • 4
  • 7
  • 11
    The technology used to log in via Facebook or Google is OAuth 2. ([RFC 6749](https://tools.ietf.org/html/rfc6749), although that RFC doesn't answer this specific question). – S.L. Barth Mar 10 '17 at 10:03
  • 2
    Hard to know without seeing more. The key rule for netword login is that your google password should never reach the third party site. – Serge Ballesta Mar 10 '17 at 10:54
  • 2
    @S.L.Barth I think the OP's concern is that the thing they are entering their FB/Google details into _may not be_ FB/Google -- it doesn't matter that their systems are safe if you're actually entering the details into a phoney. – TripeHound Mar 10 '17 at 13:50
  • @TripeHound That's why I posted only a comment, not an answer. I noted the OP seemed aware that their credentials should never be seen by the service - but never mentioned OAuth by name, or in the tags. – S.L. Barth Mar 10 '17 at 14:02
  • @S.L.Barth But -- unless I'm missing something (which is quite possible) -- OAuth has nothing to do with it. What (I think) the OP is worried about is that by not visibly showing the FB login page (where the URL's correctness can be verified) a malicious app/web-page may show a _fake_ FB window where the user enters their credentials and has their account stolen. – TripeHound Mar 10 '17 at 14:12
  • The question as it is right now is opinion-based. It should be rephrased, e.g. to ask for the downsides of this approach. – Christian Strempfer Mar 10 '17 at 21:45
  • I don't like it because of one drawback: uses same credentials across all services. That makes it quite difficult to use, say, a different email address for each site. – JDługosz Mar 11 '17 at 01:05

5 Answers5

35

I am quite sure that there are some sites which require you to login with your facebook/google account on their site (so the URL shown is not facebook/google). I am sure there are some desktop application which do this as well.

This is very bad practice for websites, because OAuth / OpenID (which are protocols used to delegate authentication) is designed to work around that exact use case. But there is no other way to do it in desktop applications, because desktop applications don't have redirect functionality.

A web page can forward you to the google or facebook authentication, where you can enter your credentials, and then when you authenticate successfully, Google / Facebook can redirect you back to where you came from.

This is impossible to do in a desktop application. One way around it is for the desktop application to open a web browser where you authenticate with your auth provider (Google / Facebook), and some magic happening behind the scenes can then authenticate you to the desktop application. But by and large this is an unsolved problem - you'll simply have to trust the desktop application to not steal your credentials. In fact opening a web browser doesn't really solve the problem either; now you're just trusting the browser to not steal your credentials (The browser is a desktop application, too!)

I have read a couple of times that using other services to login is considered good practice. Is this true?

It's considered good practice because

  1. It's user friendly - users don't have to remember a hundred different credentials

  2. On the whole it offers better security - you don't have to trust a hundred different implementations and hope every site is bug-free and stores your password safely - you only have to trust Google, or Facebook, to take care of security. And they're much more capable to do so than your teen-aged nephew who wrote yet another login system for his new site.

Of course, it also means you're now putting all your eggs in one basket. If someone breaches your Google / Facebook account, you're in much bigger trouble if you use that account to authenticate on a hundred other sites. Also, there are privacy issues in letting your auth provider know which sites you visit and with what frequency you sign in.

Out of Band
  • 9,200
  • 1
  • 22
  • 30
  • 13
    Fun fact: For flickr, this "magic behind the scenes" actually works. I know that with Darktable (a FLOSS photo editor), you can upload directly to flickr. Darktable would tell you "I will now open a URL with your favourite browser, click OK after you confirmed there" and then in your browser a tab opens with a Flickr page asking you for confirmation. Darktable is then authenticated, I assume it polls some URL to know it has been authenticated. This is to say "it is not impossible to do something like OAuth in desktop applications safely". You have to do that every time, so it’s not permanent. – Jonas Schäfer Mar 10 '17 at 14:01
  • 3
    The "magic" is indeed a direct access from the app to the OAuth API of the auth provider. The app has a pre-arranged api key for that purpose, and the login link it opens in the browser contains an id so that linking the authentication with the app works. And there actually are flows for OAuth which would allow Darktable to "permanently" get access to your flickr account so you'd only have to authenticate once (at least if you used Darktable often enough not to run into refresh token expiry problems). – Out of Band Mar 10 '17 at 16:01
  • 1
    The Google Cloud Platform command-line interface uses a similar mechanism (launch the browser to retrieve an OAuth token) to authenticate to the various GCP management APIs. – mfsiega Mar 10 '17 at 16:02
  • 2
    Ironically, Facebook itself still asks for your credentials on other sites if you want to import your contacts from them. – GnP Mar 10 '17 at 18:24
  • 1
    You "unsolved problem" statement is pretty much incorrect. Several desktop applications are very much able to do this without issues, including Skype and Visual Studio. – T. Sar Mar 10 '17 at 18:31
  • 2
    @TSar: I'm not saying you can't authenticate in a desktop app - just that you have to trust the application into which you enter your credentials not to steal them. Admittedly, thats fairly obvious and unavoidable. An improvement would be to integrate delegated auth into the OS - but AFAIK, there is no widespread OS support for delegated authentication yet. MS Azure Auth might be an exception, but one limited to MS as an auth provider. – Out of Band Mar 10 '17 at 19:33
  • 1
    Also: if you are using a Desktop application it could trivially integrate a keylogger, thus rendering entering your credentials via browser exactly as insecure as doing so from the application itself... it only gives a false sense of security that the application is unable to obtain your credentials... – Bakuriu Mar 10 '17 at 20:03
  • @Pascal The same goes for a web app. You can't be sure that the window the app is showing is the legit one. Most regular users don't even notice the address bar. – T. Sar Mar 10 '17 at 20:03
  • 1
    @Bakuriu - Yes, I agree, using the browser isn't foolproof either. Really the only way to solve it would be to move entering the credentials into a OS service - you have to trust the OS anyway. TSar: Sure, people are people. There's no way around that :-) – Out of Band Mar 10 '17 at 22:08
  • 1
    @Pascal An OS service would be an improvement, but even then as long as an app has the ability to draw things to the screen it can probably fake whatever OS auth dialog is available. In the end on your average desktop OS without heavy sandboxing and app isolation having an evil app on your system is game over. – Vality Mar 11 '17 at 02:14
  • I think you should clarify that point 2 is moot if you use different passwords on each site. In fact, for poorly implemented home brew security, logging in with oauth might be more dangerous, especially to less tech-savy users, as a hacker could replace the real oauth login with a page faking to be facebook/google. That might trick many users, especially if they are already used to the site. – Sebastiaan van den Broek Mar 11 '17 at 05:38
  • 2
    @Vality So much that! It’s drifting to off-topic, but that’s the reason I cringe when people think that ``curl | sh`` or any other "oh, that’s an easy installation process" is a good idea. – Jonas Schäfer Mar 11 '17 at 08:04
  • 2
    @SebastiaanvandenBroek that's exactly the biggest problem I see with this. Even tech-savvy users can be fooled by domains that look alike, or simply forget that it's not safe if there's no separate login window. I was always taught 'Never give your password of one service to another'. This approach can convince users that it is OK to do that. I bet that a reasonably popular service could convince a large part of their users to give up their facebook/google logins. Still, I don't think it matters a lot since many people use a single login for many services. – Ruben Mar 11 '17 at 14:19
  • 1
    It is perhaps worth noting that even if it launches a web page, you still have to trust the desktop app didn't install a key logger to steal credentials. – jpmc26 Mar 12 '17 at 02:19
  • An OS service, like a web browser included in the OS? The problem with using an in-app browser to login is that it's usually not as up-to-date as a proper browser. It also opens up issues like the app not implementing certificate checking (or EV bar) properly and not being able to use existing cookies. – Lie Ryan Mar 12 '17 at 02:57
  • No, just something you trust not to steal your credentials. Basically a two-field input dialog you trust, which will then authenticate with the auth provider. Its doable, but like @Vality says, you need something like Qubes OS to make it foolproof. – Out of Band Mar 12 '17 at 08:32
6

First part is mainly a partial answer for the desktop application case. Installing a desktop application is not the same as browsing a remote site. In the latter, you trust your browser to protect you (as much as it can) from possible attacks. In the former, you must trust the application to not contain malware. I make little difference between trusting chrome not to send all my personnal infos to Google, and trusting a NVidia app not to steal your Google password.

The only real difference is that you add a new possible attack place on your unique Google password. If it worries you, just create an auxilliary account, that you do not use for sensitive accesses and use it for NVidia and/or other desktop applications.

That being said, it is definitely bad practice for a site or even a desktop application to put itself on the way and take at any moment the responsability of passing your password to an external authentication service. Protocols such as OAuth or CAS were specifically designed to allow a site or application to delegate the authentication to a third party service and never see the password. The client trusts the auth. service to protect its credential, the application service trusts the auth. service to securely identify the client. Full stop. Having to trust the application service not to steal the credentials is IMHO a design error.

For the desktop use case, the correct way is to let you securely donwload the update via your browser - you take the responsability of that part - and then the application takes the downloaded file to make its updates. That way, if something goes wrong (for example you downloaded a compromised file from a pirate site) you are responsable for it. But some app. developpers are not always aware of who should be responsable for what...

Serge Ballesta
  • 25,952
  • 4
  • 42
  • 84
  • 2
    I agree with your point on the nvidia program. I don't particularly worry about it, since I trust them enough to provide drivers for me. However, if I were dealing with a company with less 'tech cred', I would be way more hesitant to enter my login info. – Ruben Mar 10 '17 at 12:59
3

In my opinion is not a good practice. Some questions can not be ignored:

  • Google and Facebook already explore our privacy, selling our personal information to third party companies and advertisers. It is just more food to the fish. That is why they provide this service.
  • Like @Pascal says, all eggs in same basket, trusting in a third party. Not quite a good option nowadays.
  • You can develop yourself a Oauth server, without the necessity of use Facebook or Google. This way you can be sure what are happening with your data.
rew1nd
  • 124
  • 7
  • If there's a google ad or a facebook liek button on ANY page you visit, the cookies will add 2+2 (your fb account and you visiting that site)... It's not really a matter of privacy from a security point of view. If there's the option to not store the password, and have someone else deal with it always take that option, one less door to worry about. – Иво Недев Mar 10 '17 at 16:27
  • 1
    @ИвоНедев very easy to remove the Google/Facebook cookies (Adblock) – JonathanReez Mar 11 '17 at 11:51
  • @ИвоНедев You cannot use Facebook at all, and no password store in anywhere. Just use google and you are tracked for advertising! You dont need login nowhere, google is always what what you visit, where you are, ect. – rew1nd Mar 13 '17 at 10:26
2

I believe it was this video where they discuss exactly this.

To sum it up:

"If you have the option to not store the password, and not deal with it, but rather have someone else (preferably bigger) do that for you, always choose that option. This will be one less potential problem to worry about."

Иво Недев
  • 170
  • 10
-1

Well, if Google and Facebook use it, one has to be a tad picky not to consider it a best practice. They have the best authentication people in the world and seem to feel comfortable with OAUTH2.

It has it's benefits - you don't have to write password maintenance code, you can be pretty comfortable their code is thoroughly tested, etc. One of it's drawbacks is that it can be a hassle to test within your app, and your users have to have an account on a provider.

Having said that I no longer use OAUTH2, moving to Two Factor using sms and challenge codes. I was surprised how it easy it was to wire up, none of the above drawbacks hold true - easy to test and people are much more likely to have a cell than account. It is quite inexpensive (tho OAUTH2 is free), and I for one feel it is more secure. Of course, YMMV

Mark Aurit
  • 9