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.

Improve this question
7
  • 11
    The technology used to log in via Facebook or Google is OAuth 2. (RFC 6749, although that RFC doesn't answer this specific question).
    – S.L. Barth is on codidact.com
    Mar 10, 2017 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, 2017 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, 2017 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 is on codidact.com
    Mar 10, 2017 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, 2017 at 14:12

5 Answers 5

Reset to default
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.

Improve this answer
16
  • 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, 2017 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, 2017 at 16:01
  • 2
    Ironically, Facebook itself still asks for your credentials on other sites if you want to import your contacts from them.
    – GnP
    Mar 10, 2017 at 18:24
  • 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, 2017 at 19:33
  • 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, 2017 at 8:04
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...

Improve this answer
1
  • 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, 2017 at 12:59
4

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.
Improve this answer
3
  • 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, 2017 at 16:27
  • 1
    @ИвоНедев very easy to remove the Google/Facebook cookies (Adblock)
    – JonathanReez
    Mar 11, 2017 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, 2017 at 10:26
3

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."

Improve this answer
-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

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .