Bitcoin website operators: please consider using Google sign-in

[Mike Hearn]

I posted something similar to this a year or two ago, now with the price over $30 it's a good time for a reminder. Full disclosure: for those who don't already know me, I work for Google on the account security systems.

If you're building a website that has a concept of logged in users, your most likely approach is to implement your own cookies-and-account system yourself. I'd like you to consider outsourcing that via OAuth2/OpenID Connect, which (if you have experience with previous systems) is a lot simpler and more straightforward than it has been in the past:

   https://developers.google.com/accounts/docs/OAuth2Login

Although it might seem easy to build your own accounts system, consider the features that using Google accounts gives you for free, that otherwise you'd have to write yourself:

• Email verification
• Password recovery for when users inevitably forget
• Sign-up UI (possibly with CAPTCHAs and more)
• Change password, delete account functionality
• Password anti-brute forcing system (block attempts to guess at high speed - this is frequently overlooked)
• Sign out
• Secure backups of the credentials database

That's the very, very basic set of features virtually all websites need. But you and your users also get access to all of these extra things, for free:

• Most importantly: no storage of user credentials on your site: if you get hacked you don't have to worry about how to manage a global password change because the access tokens already expired.
• Very sophisticated anti-brute forcing logic that blocks password guessing attacks whilst making it hard to DoS the real user
• 2-factor authentication using phone numbers, smartphone apps or YubiKeys.
• Anti-hacker risk analysis for users who don't want to bother with 2-factor auth. This is the part of the system I worked on. Also extends to the lost password recovery system.
• Single-sign on: many of your users already have Google accounts and are logged in, so a one-click authorization flow for your website is convenient, especially true if they're accessing your site from a mobile device or tablet.
• A full-time team of people who fight bulk account creation on your behalf using phone verification, machine learning, obfuscated javascripts etc.
• Automatically get access to ongoing security improvements we make, like the recent research into new kinds of hardware for continuous authorization and various anti-XSS mitigations.
• If you want it you can ask for access to users names/profile photo/language/timezone/country etc, and Google+ integration, including one-click web install of your services Android app, interactive G+ posts and other optional toys. But note that a Google+ profile is NOT required for people to sign in to your website.

In short, you probably can't match the investment large companies make into their account systems, but you can re-use it easily. All but the most security-conscious of your users will be safer if you do.

I can easily anticipate what some people may say so here's a little FAQ:

How easy is it?

Pretty easy. There is a "Sign in with Google+" button but you don't want that, because it requires the user to have a G+ profile. Instead this is the doc that's needed:

   https://developers.google.com/accounts/docs/OAuth2Login

After setting it up, users come back to your site with an access token that you can use with a REST API to get access to the users email address (if you want it). You can just use the email address as a user ID in your database, as per normal. There are libraries available for common languages to simplify things further.

Privacy?

There's some impact: Google knows which websites the user has signed in to. You have to provide a name to register a Google account, but there's no requirements on "real-ness" if you don't opt-in to Google+, so if someone wants to do a Satoshi they can. Unfortunately phone verification is required to sign up via Tor, as part of the bulk signup/abuse controls.

Depending on the nature of your website, you'll have to decide how important this is vs the extra security systems you get access to.

Is it really more secure?

Whilst a small number of users might generate 24-character random passwords for every website they visit and never get phished, most people are lazy and being a Bitcoin website doesn't change that. At Google we have routinely seen spammers try 1 million passwords per day, typically stolen from small websites like yours. As the Bitcoin world knows well, hashed passwords can be reversed at high speed using video cards. So not having to deal with passwords is a big win. As is easy access to free 2-factor auth.

[CIYAM]

Just wondering is this different from using https://www.google.com/accounts/o8/id or is it the same thing (I support OpenID but not Google)?

[deepceleron]

https://exchange.bitparking.com uses Google authentication.

On the flip side of security it is less secure for users - your gmail gets hacked, bye bye Bitcoins everywhere. It also trains users that it is okay to put their Google password into the web browser when they didn't specifically type google.com.

[Mike Hearn]

As the docs I linked to say:

The Google endpoints described here align with the OpenID Connect specification, which at the time of this writing, is in early draft stage. For reference, the OpenID Connect specification is very similar to the OAuth 2.0 protocol. These Google endpoints will update as the specification matures.

So it's based on open standards, if that's what you're asking. The GWT library has a short list of other websites that you can do the same trick with:

https://code.google.com/p/gwt-oauth2/

However, the primary reason to outsource is to gain access to security features you won't build yourself. Having users sign in with Instagram accounts or whatever probably doesn't make much sense.

On the flip side of security it is less secure for users - your gmail gets hacked, bye bye Bitcoins everywhere. It also trains users that it is okay to put their Google password into the web browser when they didn't specifically type google.com.

The address bar does contain google.com, also, if you have an account you are probably already logged in so wouldn't be asked to enter any passwords at all.

Yes, it does put all your eggs in one basket, so to speak. But you can make that basket very well protected compared to lots of random small accounts on websites that only support passwords. You know, it's not feasible to change every password on every website you use every 30 days, but if sites are linked to a master account, then it's not so onerous.

[niko]

Privacy?

There's some impact: Google knows which websites the user has signed in to. You have to provide a name to register a Google account, but there's no requirements on "real-ness" if you don't opt-in to Google+, so if someone wants to do a Satoshi they can. Unfortunately phone verification is required to sign up via Tor, as part of the bulk signup/abuse controls.

Depending on the nature of your website, you'll have to decide how important this is vs the extra security systems you get access to.

Thanks, Mike. Could you explain if Google learns about the actual account of the user, or only about the fact that the user is logging into the specified Website?  In other words, would Google directly learn or deduce that I am "niko" if I logged onto this forum using Google ID?

[CIYAM]

It seems you didn't answer my question - is there anything wrong with the OpenID URL I am using (I trust that your knowledge of the system means that I don't *need* to go and read a bunch of new docs or am I wrong)?

[2weiX]

build me a working google/facebook login thing for oscommerce, I'll install it.

[CIYAM]

build me a working google/facebook login thing for oscommerce, I'll install it.

If you have mod_auth for Apache then I have pretty much nailed it - PM for details.

[Mike Hearn]

It seems you didn't answer my question - is there anything wrong with the OpenID URL I am using (I trust that your knowledge of the system means that I don't *need* to go an read a bunch of new docs or am I wrong)?

Oh, sorry, the OpenID support that currently exists still works yes. I don't know what our plans are in future for this, it sounds like there's a new version of OpenID that's being designed right now. Generally we try to avoid breaking websites. If you prefer OpenID you can continue to use it, but a lot of people found it too complicated or the user interface too cumbersome.

Thanks, Mike. Could you explain if Google learns about the actual account of the user, or only about the fact that the user is logging into the specified Website?  In other words, would Google directly learn or deduce that I am "niko" if I logged onto this forum using Google ID?

Google can see that you signed in to bitcointalk.org, beyond that nothing else is known. Put another way the flow of data is purely one way - Google sends whatever you authorize to the website, and of course it has to know which site to give access to, but no data flows from the website back into Google.

I don't know anything about oscommerce, sorry.

[CIYAM]

Oh, sorry, the OpenID support that currently exists still works yes. I don't know what our plans are in future for this, it sounds like there's a new version of OpenID that's being designed right now. Generally we try to avoid breaking websites. If you prefer OpenID you can continue to use it, but a lot of people found it too complicated or the user interface too cumbersome.

Thanks for that (and hopefully it won't be pulled anytime soon) - actually the UI side is easy - the mod_auth side was the harder part (but will keep my eyes open for updates to OpenID).

[Mike Hearn]

Yeah, the OpenID protocol is quite convoluted compared to the new one it seems (it's been a while since I looked at OpenID). But once you paid the implementation costs there probably isn't much difference from the users perspective.

[interlagos]

I bet much more secure authentication mechanizm would be for client to register its public key with the server and for the server to issue random one-time strings (for every login) that the client would need to sign with its private key stored in a air-gapped USB hardware gadget (like those USB BItcoin hardware wallets in development) and pass back to server. The server can then check if signature is valid against client's public key.

At least trojans and keyloggers won't have a chance against such system.
If (or rather when) Bitcoin hardware wallets become widespread, I assume many Bitcoin websites might consider this option.
Sorry if a bit off-topic.

[hazek]

for free:

Please Mike.  Nothing is for free, especially not anything from google. It may be gratis but it most certainly has a cost, whether it's a cost in association, or privacy, or sovereignty, there is a cost and it would be upstanding of you if you worded your posts appropriately.

[Mike Hearn]

We did that back then because there wasn't any other good way to keep people out of accounts in bulk. Since then we have made the risk analysis/id verification quiz work and don't rely on phone verification for hacked accounts much anymore.

However yes, the general point still holds - we try to avoid phone verifying legitimate accounts, but if you get confused with a potential spammer then you may have to phone verify.

interlagos, look at the research paper for the usb devices we're prototyping, they work along those lines.

[Doctor Mushies]

I don't think the requirements were that bad to get back the account. In my case, it took just a minute and it was entirely automated.

[mareo87]

i wish google sign-in was a little different from fb/twitter sign in.

maybe make use the two factor authentication instead of having to input password to log in. (for people who use two factor)

[dserrano5]

I'm for this as long as I still have the option of having a site-specific user/pass combo. I'm no longer a google or facebook user, I have never been a twitter or openid user, and I don't want to create an account there in order to log into a third site (ok ok I still remember my gmail password and in fact I get some periodic stuff there, it's just that I don't want to *use* it anymore).

[Mike Hearn]

hazek, it's "free" as in you don't have to pay any money for it, and Google doesn't get any data about your users (beyond the fact that they logged into your site, as already discussed). That's pretty close to free, imho.

[nikkisnowe]

While I don't agree with a lot of Hazek's viewpoints on other issues (block size) I do agree with him here.  What is Google's angle on this?  Nobody does anything for free and if it may appear to be free now, there is some potential value to this in the future.  I have a site dedicated to bitcoin with a user login and will look into it.  Still, I have a hard time believing that Google develops anything without a strategy behind it.   The "do no evil" days are over.

[eleuthria]

I've always been afraid of sites that use Google sign-in, specifically because it makes it so easy for a phishing scam to take place.  It requires you to be on abnormally high alert at all times.  I'm fine with that, but the VAST majority of users will see Google logos and enter their information into the boxes.  By training them that this is a legitimate way to log in to non-Google sites, it makes it so much easier to creating phishing websites.