Bitcoin Forum

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 (http://zetetic.net/software-onetime).
• Anti-hacker risk analysis for users who don't want to bother with 2-factor auth (http://googleblog.blogspot.ch/2013/02/an-update-on-our-war-against-account.html). 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 (http://www.wired.com/wiredenterprise/2013/01/google-password/) 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 (https://developers.google.com/+/), 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.

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)?

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.

As the docs I linked to say:


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.


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.

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?

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)?

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.

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.


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.

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

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.

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.

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.

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.

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.

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)

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

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.

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.

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.

well, from my point of view, you never ever have to do this via that system. first of all, you only have to enter your account info if you are on a google page (URL in the browser!) and not on *their* page. second, those users who are careless, enter their gmail email address and their gmail password when creating a new account anyways. so, yes, there are phishing sites, but they are there anyways and in all other "normal" cases, this system is better.
the only reasons for not using this, as a user, is if you have a general aversion of anything by google.
in my person opinion, there should be more standard compliant identity providers from which you can choose from (just like it is with open id right now) and site specific accounts should be a thing from the past. of course, this has a large drawback … those identity providers can correlate you with the sites you visit and deduce some information. google for example states, that they don't do this ,but it would be possible … e.g. adwords would certainly profit from better classifying an account holder.

Phishing works very well for all kinds of websites though, no training required - at least we have various protections against it, most of which unfortunately I can't talk about. Obviously the risk analysis/id verification quiz is one.

nikkisnowe, we benefit in a bunch of ways. Most obviously from people valuing their Google accounts. The more valuable it is to you, the more likely you are to be signed in with it, and that means we can upsell you on various random services we offer more easily, and if you opted in to ad personalization we can also show you better ads, which makes more money, etc.

Also, Googles whole business is predicated on the internet and "cloud stuff" being successful and credible. When users read about websites getting hacked every week, that damages the credibility of the entire internet and reduces peoples trust in all technology. So having websites outsource their auth systems to us means that those sites can be a lot more secure, which helps build trust and increase internet usage. That by itself is a good enough reason to do it (same reason we develop Chrome, no direct benefit but if the web is better, all our other businesses benefit).

And guys, remeber: the safest place to store the keys to your house is at the police precint. It saves the police the expense of getting a warrant when they will need to serve and protect you.

Anyone has any links to what Google does when they get a subpoena for the login credentials? The police must love OpenID.

I'm just playing devils advocate by my recent post.  I do think that Google's strategy is correct: what's good for the internet is good for Google.  Of course you had to have realized that questions like Hazeks were going to come up when you are promoting a form of centralized control on a forum where Decentralization is the core concern of many of the users.  Kudos and credit to you for taking on that challenge.

A friend of mine who I respect just posted this
http://labs.newsint.co.uk/blog/2012/10/why-mozilla-persona-is-the-right-answer-to-the-question-of-identity/

Those are all valid criticisms of the old versions of these protocols, which is why it's 2013 and we're still releasing new versions of "how to log in via a third party". The new OAuth2/OpenID Connect stuff is a lot easier to use than the previous OAuth1/OpenID "classic".

The strategy is to get as much integration and dependance as possible and have as many google signups as possible and with it influence and market share. If you implement their login infrastructure, your users automatically have to become their users. Pretty simple math.

Btw I'm not saying using their infrastructure isn't viable or will automatically harm you in some way, I'm just complaining about Mike saying that the use is free. It's not. It's gratis and I think the distinction is important.

I'd note that you can run your own system and third-party login systems in parallel. For google signins you just leave the password column in your database blank. Of course then you're not saving as much work, but for instance if you have 1000 users and 900 of them use a third party auth service, maybe it's feasible to do password recovery requests by hand instead of writing your own code for it, whereas it wouldn't be if 1000 users were forgetting their passwords. So it can still save you time overall.

I do understand what Mike is saying, however, what about those of us who don't want a google ID? For all I know google will be seen as the most draconian and destructive force ever created by humanity in 10 years.  I would not want them to ID me then. In fact the future of the internet for me is centered on anonymity. I doubt i will use the internet much at all compared to the TOR network.

It is actually very easy to use both, Google and Persona, on a single website. That way users can decide which one does fit them better.

well, for you, but for >99% it will be centered around identity and associated services. that's what google has in its vision because from their POV it will happen. and there isn't much doubt about that at all.

besides that, the word "open" in openID implies that anyone can start creating and promoting it's own identity provider. it's just that google has already invested a lot into such a service and newcomers have a hard time to catch up with their advantage -- purely technical speaking.
generally speaking, if all actions taken yield to a situation, where there are more possibilities, it is overall better … and that's what's happening here. (heinz v. foerster)

That is the reason for open standards.  If you support Google logins in this way, it is easy to support other OAuth-like providers who are not named Google.  :)

From a bitcoin website operator's standpoint, the biggest concern is not privacy, but giving a single entity a big fat "off switch" to your website.  If Google decides you are malicious (unlikely) or receives a court order, 100% of the Google-login-based users cannot access your website.

This problem is a general problem of interfacing with any large, 3rd party account system, and is not specific to Google.  As long as you have account recovery procedures in place, creating a contingency for en masse account blocking, I would definitely endorse Mike's points here.

If you're worried about that (it would be largely unprecedented), ask for users email addresses so you can email them with a password setup link.

Thanks for the replies guys. It looks like theres a bit more to it than I know. I guess I'm just becoming increasingly skeptical of Google. Their motto is "do no evil". But then they go out and cooperate with the Chinese government to limit free speech and help enforce anti-freedom efforts. I just don't trust Google any more. 

You know that Google stopped operating filtered search in China years ago, right?

   http://googleblog.blogspot.ch/2010/01/new-approach-to-china.html

Mike...

How would this implementation benefit Google?

Thanks.  :)

yes, but they only seemed to really back-off once they were the specific target of the Chinese. Not exactly an act of courage. I don't mean to just blame them either. Cisco makes special routers that keep the "great firewall of China" operational, and there are many others who are complicit.
Eventually they will come home crying when their servers are bled dry by government backed thieves who will vacuum up years of product development and research. I don't know when we forgot that China is a cruel and brutal totalitarian regime. We should be destroying their wall and placing the news of the world in front of their citizens.
Remember this guy?
http://static3.businessinsider.com/image/4b87e36f7f8b9aee758f0000/tiananmen-square.jpg 

This image is virtually unknown in China. That's what suppressing the truth is all about.

I am working on a website and while the idea of handing off the authorization portion to a third party seems tempting I can think of two things that would hold me back.

One, I am giving away a portion of my site's security to a third party with only the hope that they will not abuse it. I may as well have all BTC transactions handled by MtGox and content controlled by Wikipedia. While I do not believe Google's business model would last if they abused the access of websites, I still do not like the idea of handing such control over to someone else.

Second, as a user I tend to avoid sites or apps that require access to my Facebook or other accounts. I may trust Facebook or Google to keep my information secure and private but I do not trust XYZ site to use that information the way I originally intended.

I may consider giving users options of security. With the highest security being the use of their private key to sign something for each login and perhaps the lowest being a Google or other third party auth.

You probably mean authentication.  Authentication is about who someone is.  Authorization is about what people are authorized to do.  Access control is what you do when you apply the authorization rules in your systems.  Thus the access control normally requires authentication to work.  The part that this thread is about is authentication.

I'd suggest website operators take a third approach: support Google Authenticator, or to be exact, RFC 6238 time-based one-time passwords. Basically under the hood it uses a secret key, which is cryptographically hashed with the current time, and that creates a secondary password. For your users they just install the Google Authenticator app on their smart phone, use the camera to scan a special QR code containing the secret key, and from then on after enter the 6 digit one time password every time they login in addition to their normal password. Blockchain.info and many other Bitcoin sites already use it, not to mention non-Bitcoin sites. You do need a smartphone, but they're pretty common these days. Unless hackers get your users password and their phone, they can't do anything.

Unlike Mike's suggestion of using Google sign-in, RFC 6238 doesn't send any information what-so-ever to third parties. Not when you login, or even that you are using Google Authenticator at all. For non-Bitcoin sites, I can see why Google sign-in could make a lot of sense - if you use Google analytics Google already knows when your users sign in anyway - but Bitcoin is a target and you really don't want to be one court-order away from suddenly finding that none of your customers can login. Google has a better track record than most of fighting court orders, but because they're infrastructure and employees are spread out across the world in most countries they have no choice but to follow court orders. For instance Google has an office in Argentina, and I could easily see a court order to force Google to block sign-ins to Bitcoin exchanges pushed through under the guise of enforcing that countries capital controls. Equally I can easily imagine Google getting a court order by the Argentinian government forcing them to reveal all the Google sign-in's made in that country in an attempt to identify and prosecute people violating those same capital controls. Your website wouldn't even have to be based in Argentina for any of this to happen.

Mike has a point about Google sign-in being "one strong basket", but court orders can do things no attacker ever could, and if your risk is court orders, centralization is the last thing you need.

Coming Soon...

If the history is any guide openly blocking is least of the worry.

I have no data to compare Google legal eagles with Microsoft legal eagles, but Microsoft has about a decade more of the experience with their Passport and Live ID products. And before that Novell, Compuserve and Shiva, three other early pioneers of "single sign on service". Too bad that Netscape & AOL had purged all the old Compuserve forums. There were some nice stories to re-tell from some of the non-English language boards.

The problems are completely non-technical and non-cryptographic, they are all human factors and human resources issues.

Why depend on third parties, why not use PKI?  Something like ssh maybe?  I have been using PKI to log in my servers via ssh, since it adopted ECDSA, and made life so much easier without having to remember passwords (just the password for encrypting the private key).

When you register, web sites could ask you to paste your public key (in base64).  Then ask you to confirm the hash of the public key (in base58), via email just to make sure. Or visually, if there is no email required for registration.

This could be made user friendly, via a plug-in in Firefox/Chrome.  Or even better have native support for this in Firefox/Chrome.  If private keys are stored locally, they obviously need to be encrypted.

well, you aren't forced to go "all in". you can still have your own system … the more important point is, that it is not about YOUR security, but also in large about the user's security. e.g. do you protect your login against brute force attacks? do you offer 2-way authentication? do you have a heuristic to detect login attempts by a password thief based on e.g. the IP access pattern of the user (thief sits in another country) and ask some security question?
so, if you have all this and it's working, fine … if not, the USER has something to gain if s/he uses this system instead of yours.
and once again, you should offer both ways, it's easy to do!

Why not do X or Y or Z ... sure you can do all those things. In practice though, people usually don't. Even Paymium doesn't seem to support 2-factor auth and that's an exchange!

The advantage of outsourcing it is that you can focus on your business, rather than on re-inventing the authentication wheel. And yes, it can lead to some additional risk, no different to using virtual server providers or outsourcing your email or DNS. You have to weigh up the costs vs the benefits.

I read through the first page of this thread, but didn't read the rest, so perhaps this information will be redundant, anyway, here goes:

Firstly I'd like to thank Mike Hearn for all the stuff that he does for bitcoin at large.

Secondly I'd like to put forth my opinions about OpenID.

What if your Google e-mail is compromized, it seems then it would also be possible to get access to the sites that you're connected to through OpenID.

The privacy issues is also interesting. If a certain individual is the member of 5 sites, and all these sites run their own user account systems, then any law enforcement agency or any 3-letter agency would need to contact 5 entities to get required data. However, with one central repository, one rogue sysadmin or a request to Google from law enforcement would be enough to get the required data.

Now, most users are honest individuals doing nothing nefarious, and you don't even need to do anything nefarious to value your privacy online. But as a website operator, you're now relying on a 3-rd party for all your user accounts, and what if it's decided that pulling the plug on your website is the right thing to do, caused from legal of political pressure ? There's nothing you can do, but to see your entire userbase vanish by the snap of some fingers.

And what if some google employee fucks up, and user data is leaked ? I assume there is tight security, but tight security has been broken before. Also, google will be able to record when you log in to a certain site, and a host of other parameteres, they can and will use for various purposes that you may or may not agree with.

For example, if you are a member of some soccer sites that use OpenID, google will possibly serve you commercials for computer soccer games and so on. Google may also use your habbits as a toll to suggest stuff for you on Google+.

Make no mistake about it, although Google does a lot of good things, like drone program to help wildlife preservation, and offering a hostload of free services online, they also need and want to turn a profit, and in addition they're US based, meaning it's very easy for law enforcement and 3-letter agencies to tap into their data, and mind you - this is happening. We don't hear about it, but we should not be naive and think it's not happening.

So who knows, some years down the line, you need to pay a mandatory license for using bitcoins, and lists of users will be extract from Google, and you will have your bills in your mailbox.. Ok, that may be stretching it, but judging from all the silly things that US policy makers and law enforcement agencies actually do, I would not be surprised if this will happen. What about mining pools, I'm sure the IRS would be happy to look up personal information about big time miners to see if they're paying their taxes.

This being said, it's unquestionable that Google provides a more secure and more professional service than most devs would be able to put up alone, but it's worth knowing about the privacy implications, which can be severe.

I already see that Google is exploting my online habits to do targeted marketing in regards to my interests, and I don't like it much, but I understand why the development is going this way, and I see how it can make revenue, it's not like I would click on ads sporting womens makeup articles, give me some geeky ads, and the chance is bigger that I click on an add, and then add this up for thousands and millions of users, and we have the answer to why targeted marketing works great for google.

I'd say if you run a somewhat serious website, have your own user account system, and protect it well, two factor identification may also be an interesting thing to implement.

There is absolutely no need to have only one account type implemented.
As an example, we allow users to login using username/password, Google, Persona, or by signing a token with their bitcoin address.
For all those account types, one can enable two-factor authentication as an added security measure. By proving all those options users can decide them self, what they prefer. Keep in mind, that all types have their pros and cons.

Google sign-in isn't for everyone, but for small websites run by people in their spare time it can save a lot of hassle.

There should be something like google sign-in for wallet management too.  At the moment, if you want to run a theft-proof bitcoin website you basically need to be a security guru.  That creates a big barrier to entry and excludes a lot of mom-and-pop web businesses from the Bitcoin economy.

I think you will be pleased to learn that we have implemented this at BIPS. It was already in place at the time this thread was created but we had to wait until the site was launched to share.

For those of you who are interested, BIPS offers a free Bitcoin eWallet and free Bitcoin merchant tools.

https://bips.me