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.
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 think, there're way more disposable email services than non-authenticating OpenID servers.
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.
The weakest link of security is always the human factor.
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.
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.
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.
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.
Even worse, the domain used varies based on your card issuer so there's no consistency.
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.
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…)
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:
Our framework notices stuff like this and just "does the right thing"
This piece of writing posted at this site is
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.
This one has the makings of a programmer.
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.
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.
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.
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.
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.
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.