How People Think Facebook Connect Log‑in and Log‑out Work(skinnywhitegirl.com)
skinnywhitegirl.com
How People Think Facebook Connect Log‑in and Log‑out Work
http://skinnywhitegirl.com/blog/how-people-think-facebook-connect-login-logout-work/861/
19 comments
I favor using independent accounts, but I never mind using OpenID for insignificant site access, when more sites were implementing it back then (not sure why it isn't used much lately).
> (not sure why it isn't used much lately)
Because it never gained traction and Facebook Connect pretty much killed it because it doesn't require setup of an additional service. Mind you, Facebook Connect is a big privacy and security risk, but it's much 'easier' to a user than setting up OpenID, which is why it won.
I only hope Persona takes off, as it's a much better solution.
Because it never gained traction and Facebook Connect pretty much killed it because it doesn't require setup of an additional service. Mind you, Facebook Connect is a big privacy and security risk, but it's much 'easier' to a user than setting up OpenID, which is why it won.
I only hope Persona takes off, as it's a much better solution.
I'd be so much happier implementing Facebook Connect if it gave me an OAuth scope that didn't include access to your friends list. I don't WANT that access, so why don't you provide a way for me to not look sneaky to your users?
I avoid implementing OpenID because "auth anything" OpenID servers are a massive spam vector. Very annoying.
How do OpenID logins compare to "classic" email-confirmed registrations in this aspect?
I think, there're way more disposable email services than non-authenticating OpenID servers.
I think, there're way more disposable email services than non-authenticating OpenID servers.
Yeah. I almost throw up a little when i read that.
Knowledgeable users should not be punished because of dumb users.
If your system sucks, make it suck less. Don't remove options. Add friking paragraphs of well written short copy explaining the issue and create a better world. with less dumb.
I'm afraid people like this is working for Mozilla... Afraid Mozilla 30 will be gnome 3.
Knowledgeable users should not be punished because of dumb users.
If your system sucks, make it suck less. Don't remove options. Add friking paragraphs of well written short copy explaining the issue and create a better world. with less dumb.
I'm afraid people like this is working for Mozilla... Afraid Mozilla 30 will be gnome 3.
Nor should dumb users be punished because of knowledgeable users. Facebook ain't exactly the service of power users. Leaving Facebook logged in on a public computer has some nasty security consequences.
The weakest link of security is always the human factor.
The weakest link of security is always the human factor.
I just wish we'd commonly use self-owned/self-issued digital certificates at some point in the future.
Actually, the issue is that the site in question implemented it wrongly, and the users have the correct mental model. On my site, the users in red would actually be correct, i.e. logging out of my site would log you out of Facebook. This is also the more logical, consistent and secure approach, because if the user stays logged in on Facebook even after pressing "log out" on my app, just pressing the "connect on facebook" button again would log the user in without asking for a password. This is not secure.
It's quite simple: when a user is signed out on your app, use the javascript SDK to sign-out the user from Facebook as well. You can easily do this by loading the SDK, subscribing to the status-event, and if (user is not signed in in my application) && (facebook SDK says user is signed in to facebook), then call FB.logout().
This is a workaround though, you should just combine both when pressing the "sign-out" button of your website - i.e. send an ajax request to the sign-out page, send an FB.logout request to facebook, redirect user when complete. That has the added advantage that any time a user visits your page, and the client-side SDK tells you the user is connected through Facebook, you can automatically sign-in that user.
I've just completed going through the API and everything so I have a pretty good grasp of things right now, I should write a blogpost about how to properly implement Facebook sign-in, because Facebook is traditionally quite lacking on documentation, and definitely doesn't give a clear view of best practices.
It's quite simple: when a user is signed out on your app, use the javascript SDK to sign-out the user from Facebook as well. You can easily do this by loading the SDK, subscribing to the status-event, and if (user is not signed in in my application) && (facebook SDK says user is signed in to facebook), then call FB.logout().
This is a workaround though, you should just combine both when pressing the "sign-out" button of your website - i.e. send an ajax request to the sign-out page, send an FB.logout request to facebook, redirect user when complete. That has the added advantage that any time a user visits your page, and the client-side SDK tells you the user is connected through Facebook, you can automatically sign-in that user.
I've just completed going through the API and everything so I have a pretty good grasp of things right now, I should write a blogpost about how to properly implement Facebook sign-in, because Facebook is traditionally quite lacking on documentation, and definitely doesn't give a clear view of best practices.
That's also potentially problematic though. I'm not a regular Facebook user, but re-cast in terms of Gmail - if your site logged me out of Gmail every time I logged out of your site, I'd get quite annoyed (and probably quickly stop using your site).
Perhaps if your site can detect at login time whether I was already logged in to the site providing the OAuth service (maybe you could use time-to-authenticate, if there's nothing in the API to tell you?) - and only call OAuth-providor.logout() if you knew your site/login triggered the original OAuth site's login - leaving the Facebook (or Gmail) login session active if it was already there before I used it to log in to your site.
Perhaps if your site can detect at login time whether I was already logged in to the site providing the OAuth service (maybe you could use time-to-authenticate, if there's nothing in the API to tell you?) - and only call OAuth-providor.logout() if you knew your site/login triggered the original OAuth site's login - leaving the Facebook (or Gmail) login session active if it was already there before I used it to log in to your site.
That was how I was planning on doing it at first, indeed! But after giving it some thought that still doesn't make sense. Basically if you sign in using Facebook connect, your accounts are linked, and the third party site should be thought of as an extension of Facebook: If you're signed in in Facebook, then you're signed in to all the apps you've "connected" with. If you go to the site of an app you're connected with, the client-side SDK will alert the app within 2 seconds that you're signed in and connected, and could reasonably redirect you to the signed-in version of their site.
I think it comes down to personal preference, and if you're sharing your PC with people you trust, but a sign-out button is meaningless if "signing in" afterwards is possible without any confirmation. The only reason why you would have a sign-out button that signs you out of the third party site, and not out of Facebook, if is someone else wants to use your PC to sign-in on the third party site, without Facebook. That's such a narrow use-case though that I don't think it's worth it to mess up the user's model of security.
I think it comes down to personal preference, and if you're sharing your PC with people you trust, but a sign-out button is meaningless if "signing in" afterwards is possible without any confirmation. The only reason why you would have a sign-out button that signs you out of the third party site, and not out of Facebook, if is someone else wants to use your PC to sign-in on the third party site, without Facebook. That's such a narrow use-case though that I don't think it's worth it to mess up the user's model of security.
There are 2 issues being raised here. Firstly, Facebook Connect keeps people logged into Facebook once they've logged out of then authentication consumer site. From the user's perspective, this may be desirable behavior or not. If it's their personal desktop and they like to leave themselves logged in to Facebook then it is. If it's a shared PC at an Internet cafe, probably not. As part of the Connect API, Facebook could force the authentication consumer site to ask at the time of logout and to propagate through.
The second issue is that of honeypots and tricking people into providing credentials. People very seldom check the URL to verify that Facebook or Twitter are the actual sites that the data is being submitted to. In fact, they've been trained to do that with services like Mastercard Securecode usually implemented inside a frame to "arcot.com". This is a much bigger issue that requires a more imaginative solution.
The second issue is that of honeypots and tricking people into providing credentials. People very seldom check the URL to verify that Facebook or Twitter are the actual sites that the data is being submitted to. In fact, they've been trained to do that with services like Mastercard Securecode usually implemented inside a frame to "arcot.com". This is a much bigger issue that requires a more imaginative solution.
> In fact, they've been trained to do that with services like Mastercard Securecode usually implemented inside a frame to "arcot.com".
Even worse, the domain used varies based on your card issuer so there's no consistency.
Even worse, the domain used varies based on your card issuer so there's no consistency.
The problem of users mistakenly entering Facebook credentials into a Facebook-lookalike login form is definitely a honeypot vulnerability...but what percentage of these users would also, when asked to register an account on an entirely new service, would just end up deliberately using their same FB credentials anyway?
Phishing sites are already using the misconception that to log-in with OAuth (or OpenID, or Facebook Connect) you enter your username and password on the site. I wrote about it last month after a friend got caught by a phishing scam. http://www.antoncohen.com/2013/05/phishing-failure-of-oauth....
Logging out of the service can log you out of Facebook. Depends how Connect is implemented by the service. See Airbnb as an example.
I like the idea others had of just logging you out of facebook too.
The honeypot problem I think is most serious. That can be mitigated by having a 'challenge' question (e.g., "What is your favorite...") on the SSO managers such as facebook.
But I think the better solution is that we seriously need to push browsers to encourage public/private key auth. That we don't have public/private keys standardized and easy to use is a shame. You could just have a little button on the browser that asks for a global password. When entered, it then populates your user-agent with your public key, and a localhost cookie with your private key. Then this entire mess maybe goes away (but I'm no security researcher). Maybe we could even then encrypt text boxes easily. That would be something: right click a text box and select 'PGP' etc.
The honeypot problem I think is most serious. That can be mitigated by having a 'challenge' question (e.g., "What is your favorite...") on the SSO managers such as facebook.
But I think the better solution is that we seriously need to push browsers to encourage public/private key auth. That we don't have public/private keys standardized and easy to use is a shame. You could just have a little button on the browser that asks for a global password. When entered, it then populates your user-agent with your public key, and a localhost cookie with your private key. Then this entire mess maybe goes away (but I'm no security researcher). Maybe we could even then encrypt text boxes easily. That would be something: right click a text box and select 'PGP' etc.
The problem is - browsers != people. I have 3 browsers open on this machine, another 3 browsers on the phone in my pocket, four browsers on my iPad, and at work I keep separate browsers up logged in as either me-at-work or me-personally. There are also a few machines/browsers I use more-or-less regularly which aren't "mine" (the meeting room and board room machines, the girlfiend's laptop…).
While client certs "work" (StartSSL.com's login for example), they fall a fair way short of "working well across multiple devices". (I'm not even sure if I could install a client cert on Safari/Chrome/AtomicWeb on iOS if I wanted to.)
Maybe something like Chrome's bookmark/tab syncing could be extended - but I'd want it to work across Chrome/Firefox/Safari on at least OS X, iOS, Android, and Linux (and though not important for me, it'd need to work with IE on various Win versions too, if it's to get any real market penetration). I fear there's no secure way to make that happen though - who's "cloud" could you trust with your private key? (Hell, can you even trust Windows with your private key? I've _still_ not put my real GPG key onto my iPhone because I'm not convinced that'd be smart…)
While client certs "work" (StartSSL.com's login for example), they fall a fair way short of "working well across multiple devices". (I'm not even sure if I could install a client cert on Safari/Chrome/AtomicWeb on iOS if I wanted to.)
Maybe something like Chrome's bookmark/tab syncing could be extended - but I'd want it to work across Chrome/Firefox/Safari on at least OS X, iOS, Android, and Linux (and though not important for me, it'd need to work with IE on various Win versions too, if it's to get any real market penetration). I fear there's no secure way to make that happen though - who's "cloud" could you trust with your private key? (Hell, can you even trust Windows with your private key? I've _still_ not put my real GPG key onto my iPhone because I'm not convinced that'd be smart…)
We had to tackle all these kinds of things when building the Q framework. You can see the result at http://qbix.com login
Consider this ... what if on a public computer, User X is still logged in with Facebook, and User Y is logged in with Twitter. In the past, both used Facebook, Twitter respectively to auth with our service. Now, which user should be logged in?
Or consider that the user could have logged out of facebook and another user logged in, while our site was in the background. The user comes back to the site, and what should we show?
Well, we show this:
http://cl.ly/image/281I2T2H0W33
http://cl.ly/image/1C1l0A2n1U3V
Our framework notices stuff like this and just "does the right thing"
Consider this ... what if on a public computer, User X is still logged in with Facebook, and User Y is logged in with Twitter. In the past, both used Facebook, Twitter respectively to auth with our service. Now, which user should be logged in?
Or consider that the user could have logged out of facebook and another user logged in, while our site was in the background. The user comes back to the site, and what should we show?
Well, we show this:
http://cl.ly/image/281I2T2H0W33
http://cl.ly/image/1C1l0A2n1U3V
Our framework notices stuff like this and just "does the right thing"
OT: your blog is being overrun with comment spam.
I am regular reader, how are you everybody?
This piece of writing posted at this site is truly nice.
This piece of writing posted at this site is truly nice.
From a clarity perspective, I really like how Stackoverflow.com (or StackExchange in general) implements this. When you go to login, it presents clear icons to choose from, but no form fields. You have to explicitly choose what you are logging in with.
That said, it does not address the security concerns raised by the article. The honeypot problem is a pretty prolific one. Same can be done for any provider that implements it's authentication for 3rd party websites. I'm sure there is some policing going on from FB/Google/etc, but not sure on the effectiveness.
That said, it does not address the security concerns raised by the article. The honeypot problem is a pretty prolific one. Same can be done for any provider that implements it's authentication for 3rd party websites. I'm sure there is some policing going on from FB/Google/etc, but not sure on the effectiveness.
> User 4) “Yes. I do not see a separate window for my facebook site so I would assume that Buyosphere would have set it up to log me out when I’m done on their site. I think I can check to see if I’m logged out by opening facebook and seeing if the login boxes come up or if it takes me straight to my FB page. I will try it right now….I was wrong it didn’t log me out. I am surprised by that. That makes the process of logging off take longer if I have to log out of this site and then go to FB to log out of that site separately.”
This one has the makings of a programmer.
This one has the makings of a programmer.
Two things:
First off, having multiple login systems doesn't necessarily enable you to honeypot credentials off of people that wouldn't otherwise give them. The people using Facebook credentials to try to log into a site with Facebook Connect is probably going to reuse the same username and password when they register for your site. People who don't understand security are completely terrible at password reuse discipline.
Second, the solution to this requires a collaborative effort from both the auth provider and consumer. If I sign into Facebook and check "This is a public computer", then Facebook should remember that. Then, Facebook should provide a "finishSession" API call or whatnot, which a site calls when the user logs out. This lets Facebook determine what to do with the user's facebook.com cookies - if it's a transient session, wipe them. If it's a persistent session, don't do anything with them. OAuth clients shouldn't have to care about the semantics of the Facebook login - just like authentication is delegated, so should management of the user's session be delegated.
This would preserve user expectations in both cases.
First off, having multiple login systems doesn't necessarily enable you to honeypot credentials off of people that wouldn't otherwise give them. The people using Facebook credentials to try to log into a site with Facebook Connect is probably going to reuse the same username and password when they register for your site. People who don't understand security are completely terrible at password reuse discipline.
Second, the solution to this requires a collaborative effort from both the auth provider and consumer. If I sign into Facebook and check "This is a public computer", then Facebook should remember that. Then, Facebook should provide a "finishSession" API call or whatnot, which a site calls when the user logs out. This lets Facebook determine what to do with the user's facebook.com cookies - if it's a transient session, wipe them. If it's a persistent session, don't do anything with them. OAuth clients shouldn't have to care about the semantics of the Facebook login - just like authentication is delegated, so should management of the user's session be delegated.
This would preserve user expectations in both cases.
I wonder if a metaphor for sign-on services would help disambiguate this?
Would using your "Facebook Card", perhaps signified with a little "ID card" icon be more comprehensible than the "Connect with..." or "Sign in with..." which look very much like a sign-in to the source.
I'd expect many people already have a mental model of an ID card or badge granting "local" access to different things.
Would using your "Facebook Card", perhaps signified with a little "ID card" icon be more comprehensible than the "Connect with..." or "Sign in with..." which look very much like a sign-in to the source.
I'd expect many people already have a mental model of an ID card or badge granting "local" access to different things.
There would still be some people that would think "Well I'll just enter my Facebook credentials to verify my Facebook Card". The problem the site creates is the login form that has a username input, password input, and a "Connect with Facebook" button. The user interpreted it as "If I type in my FB credentials and click this FB button, then FB logs me in."
Instead, they should start with making the user pick "1) Log in using a Buyosphere account, or 2) Log in using Facebook Connect". It's much less user friendly, yes, but that's the consequence of having multiple authentication systems.
Instead, they should start with making the user pick "1) Log in using a Buyosphere account, or 2) Log in using Facebook Connect". It's much less user friendly, yes, but that's the consequence of having multiple authentication systems.
Doesn't this just reinforce the fact that using a third-party service for authentication is a bad idea? Most users don't understand it. You app is, generally, forced to ask for more permissions than desired. And you are at the mercy of the third party. I don't see any way in which a third party authentication service is a win.
It's a win because users aren't forced to go through the typical create username/password --> email verification --> sign in flow. Is it worth it to the end user? Maybe, maybe not. But it saves them time, and there's lots of empirical evidence that sign-up rates are drastically higher with social login.
>and there's lots of empirical evidence that sign-up rates are drastically higher with social login.
Where? I've never seen any evidence at all, just claims from social marketing weasels. The only empirical evidence I've seen shows it doesn't help at all, and that the majority of users don't like it.
Where? I've never seen any evidence at all, just claims from social marketing weasels. The only empirical evidence I've seen shows it doesn't help at all, and that the majority of users don't like it.
I'm all for Oauth integration in principal, albeit the "standard" has its (reasonable and well-criticized) issues, but I think there's more of a case to be made here for what's important to highlight to avoid user error on the part of the web browsers / clients themselves.
Maybe incognito mode should be the default state of any new browser install and non-incognito is a preference or toggle? This would avoid mass consumer public consumption auth issues.
Maybe incognito mode should be the default state of any new browser install and non-incognito is a preference or toggle? This would avoid mass consumer public consumption auth issues.
To me the moral of the story is to include a notice that the user has only logged out of this (the auth consumer's) site, but may still have an active session with auth provider X. That exact language probably isn't appropriate, but it's at least the information a responsible auth consumer should try to convey.
[deleted]
This is context scramble. Why would anyone think they'd be logged out of Facebook because they logged out of a site that uses Facebook auth? That'd be like expecting you to have to unlock your front door again because you locked your car.
Because else logging out is meaningless - just pressing the "connect with facebook" button again would instantly the user back in, without asking for confirmation or a password. Hardly secure.
> Why would anyone think they'd be logged out of Facebook because they logged out of a site that uses Facebook auth?
Because logging in was associated with Facebook, the log out got associated as well? As you said, context scramble. I think this was the point of the author; it's a bit too easy to mix up logging in and logging in with.
Because logging in was associated with Facebook, the log out got associated as well? As you said, context scramble. I think this was the point of the author; it's a bit too easy to mix up logging in and logging in with.
To reinforce the analogy: with the same key.
[deleted]
[deleted]
Those of us that use LastPass / 1Password are better off creating independent accounts with separate passwords rather than centralizing auth to a service that still basically relies on a single username / password combo.