Telcos Gear Up To Fight Facebook and Google Over How You Log Into Websites (mashable.com)

Mashable has an interesting article that talks about the penetration of "social authentication" services: There are two ways to log in on websites: try to recall the email address and password you registered with -- or simply hit the "Facebook Login" button. The convenience of the latter underscores the popularity of social authentication options. You'll see Facebook and Google login buttons on popular sites including Netflix, Uber, Spotify, Imgur and Linkedin, just to name some. Facebook itself estimates that some 350 million people log into a new app or site with their Facebook credentials every month. Olga Kuznetsova, Engineering Manager at Facebook told us that the Facebook Login button ranks in the top three of consumer account creation and sign-in preferences worldwide. More than 85 of the top 100 apps in the U.S. market use Facebook's Login gateway as a login, she added. For years, Google and Facebook have assumed control over the social authentication space, the article adds, citing numbers from companies and analysts. But interestingly, telecom operators are prepping to fight for a slice of the space. So-called mobile identity is one of several projects being developed in the industry to reinforce the position of network operators, which have already suffered an erosion of their traditional communications businesses by the rise of large US technology groups such as Facebook and Google, analysts say. The article adds: Mobile Connect is an authentication solution that the GSMA, the global telecoms industry trade organisation, has been working on for over three years. Through Mobile Connect, GSMA is offering users a much more convenient and "more secure" sign-in option, Jaikishan Rajaraman, global head of technology at GSMA said. The authentication service only requires users to enter their phone number when signing in. There is no password box. When a customer enters her phone number, her carrier (telecom operator, in this case) vouches for her identity. Incredibly, over 42 operators in 22 nations are on-board with Mobile Connect, and the service is already live to over 3.1 billion people. The article adds that GSMA is in talks with governments to add Mobile Connect on their websites and apps. Interestingly, banks, that have long resisted the idea of having Google's and Facebook's authentication service, are also showing interesting.

Comments

For mobile

[110010001000]

Sure, that works for mobile (I guess). Although at that point why have the user enter their phone number at all? It is already known, presumably they can map the IP (or whatever they use), to the mobile phone number automatically. We do have a Open Standard for auth, oauth. Unfortunately it doesn't generate revenue for the various conglomerates that track your every move.

Re:For mobile

[dgatwood]

The only thing I want less than Facebook vouching for my identity (and thus being able to impersonate me, see everything I do, etc.) is my ISP doing so. We're already in a situation where the privacy protections that prevented ISPs from horribly abusing that power just got shot down by Congress. And many ISPs have a long history of treating privacy as an afterthought (at best).

What we need is not federated logins. We do not need a single password on a server somewhere to be the keys to the kingdom. This is a breach of proper security design at a fairly fundamental level.

No, what we need is a law requiring all U.S. websites to A. allow autofill, B. always provide username and password fields on the same page (none of this "ask for the username, then click, then ask for the password" crap that breaks many password autofill systems very badly) and C. provide an HTTP(S) header containing the URL to an HTTPS endpoint that returns a form with four fields: username, old password, new password, and some standard checksum scheme to ensure that the form values were not truncated in transit. The form can, at the website's option, either use JavaScript (if the auth scheme requires client-side processing) or not (99.9% of websites), but submitting it must change the password unless the original password is wrong, and must trigger a full page load of a page containing exactly the text "403 FORBIDDEN" (in plain text, and nothing else) if the password change failed. (In the case of JavaScript-driven auth, this could be as simple as changing the location to /403.txt after getting back an error.)

As soon as all websites conform to that standard, passwords basically cease to be a problem. Your in-browser password manager (whether the one built into the browser or your choice of third-party extensions) can just have a "change all" button so that if your passwords get compromised somehow, you can change them all to random values and optionally sync them with whatever cloud password system it uses.

And any servers that are serious should also use cookies to keep a per-device token with some sort of callback-based verification (phone, text, email) before allowing the device to join. Such tokens should be automatically refreshed if needed as part of the password change mechanism so that changing a password doesn't invalidate the current device (and ideally should not invalidate other devices on the account). Such a website should provide a way to log out other devices. That sort of thing should, of course, be entirely optional, and is orthogonal to the password management issue, though perhaps such features should be required for any website that stores bank account numbers (not CC numbers) or provides access to bank accounts, stock portfolios, or retirement plans.

Oh joy

[Impy the Impiuos Imp]

It isn't about security. It's about tying together your surfing on disparate web sites into one big automated database to sell you targetted advertising.