After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 688364 - Does not work with Google 2-factor authentication
Does not work with Google 2-factor authentication
Status: RESOLVED FIXED
Product: gnome-online-accounts
Classification: Core
Component: general
3.6.x
Other Linux
: Normal major
: ---
Assigned To: GNOME Online Accounts maintainer(s)
GNOME Online Accounts maintainer(s)
: 688773 694996 706473 707965 707969 (view as bug list)
Depends on: 686804
Blocks:
 
 
Reported: 2012-11-15 05:59 UTC by Ivan
Modified: 2019-01-13 18:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ivan 2012-11-15 05:59:59 UTC
previous version works fine
clock is ok ru.msk.gmt+4 synced with pool.ntp.org
Comment 1 Ivan 2012-11-15 06:01:56 UTC
https://bugs.archlinux.org/task/32668
Comment 2 Debarshi Ray 2012-11-15 09:15:29 UTC
Are you using 2-factor authentication with Google? If you are, then it is better not to use GOA at the moment.

The problem is that in 3.6 we use CalDAV for Google Calendars, which does not work with OAuth tokens, only with passwords. Neither does GTalk, which needs OAuth2.

We have partly solved the problem for 3.8, by migrating our Google provider to use OAuth2. This takes care of GTalk, but the problem with calendars remain.

Google does have plans to support OAuth2 with CalDAV, but not sure when that will be available more widely. Or you can write and maintain a libgdata based backend for E-D-S till that happens.

This is only about Google. Facebook 2-factor authentication works.
Comment 3 Debarshi Ray 2012-11-15 09:17:48 UTC
See bug 687578 for why this used to "work" to some extent, but doesn't any more.
Comment 4 Ionut Biru 2012-11-15 12:01:37 UTC
i'm not using 2-factor authentication with google and I have the same issue.
Comment 5 Ivan 2012-11-15 12:44:33 UTC
i'm using 2-factor authentication, but gnome concats doesn't support, so I use my generic goofle password. and thats works fine before
Comment 6 Debarshi Ray 2012-11-15 12:52:07 UTC
Ioni, what happens if you click "log in" to refresh the account?
Comment 7 Ionut Biru 2012-11-15 13:03:52 UTC
It makes me login on google and after hitting grant access, the popup window closes and I still have the log in button with the message that the credential expired. 

Trying to set the chat available in gnome-shell, I have the authentication failed notification.
Comment 8 Ionut Biru 2012-11-15 13:34:49 UTC
update: After opening Seahorse, I noticed that I had two goa_ entries in the keyring.

After deleting them and tried to log in to refresh the credentials, everything works as expected.

I believe is a duplicate of bug 681727

@Ivan please confirm.
Comment 9 Ivan 2012-11-15 16:16:00 UTC
No it's not working for me
I've only one goa_ entry, several evolution entries and multiple google mail enrties
I erased them all and have no luck even with relogon
Comment 10 Ivan 2012-11-15 16:39:40 UTC
However I found a way to fix, thanks @Ionut showing a path

In my GOA_ entry I edited 'password' field
So I removed my generic google password and inserted google application password, I got in my 2-factor authentication page. So it's working fine now, but it should be fixed I think ti work out of box ;)
Comment 11 Debarshi Ray 2012-11-15 17:34:31 UTC
(In reply to comment #10)

So you were using 2-factor. :-)

> However I found a way to fix, thanks @Ionut showing a path
> 
> In my GOA_ entry I edited 'password' field
> So I removed my generic google password and inserted google application
> password, I got in my 2-factor authentication page. So it's working fine now,
> but it should be fixed I think ti work out of box ;)

See comment 2 for what needs to happen for it to work out of the box.
Comment 12 Ivan 2012-11-15 18:50:39 UTC
> See comment 2 for what needs to happen for it to work out of the box.

It's not acceptable solution for me to disable 2-factor authentication, and I find a way to make it works, so it's not so hard to ask an application password. And as I said before previous version works fine. Also chromium support 2-factor authentication properly, so you can use the code from here to see how it works ;)
Comment 13 Debarshi Ray 2012-11-15 19:35:13 UTC
(In reply to comment #12)

> It's not acceptable solution for me to disable 2-factor authentication, and I

Nobody told you to do so.

> find a way to make it works, so it's not so hard to ask an application
> password.

It is hard to ask for an application password without screwing up the whole UX for everybody -- including non-2-factor users.

> And as I said before previous version works fine.

It does not. You would have known if you read through the bug that I mentioned earlier.

> Also chromium
> support 2-factor authentication properly, so you can use the code from here to
> see how it works ;-)

That is a cute smiley, but we don't need to see what Chromium does. We know what is required and what the current problems are. I already described them once, won't do it again.
Comment 14 Ivan 2012-11-16 02:35:08 UTC
You guy really should look at chromium, because it used the same api to integrate with account and the same dialog with the only difference it's enable to enter application password.

Also I see a lot of sarcasm in your way to make the gnome works properly for users, making a break a lot of things previosly works goog for me and many other people. So I think that way you realy goes to say "do not use the gnome" with in 3.8 release. So good luck
Comment 15 Debarshi Ray 2012-11-16 09:09:15 UTC
(In reply to comment #14)
> You guy really should look at chromium, because it used the same api to
> integrate with account and the same dialog with the only difference it's enable
> to enter application password.

See https://bugzilla.gnome.org/show_bug.cgi?id=686804#c8 (which depends on bug 687578).

> Also I see a lot of sarcasm in your way to make the gnome works properly for
> users, making a break a lot of things previosly works goog for me and many
> other people. So I think that way you realy goes to say "do not use the gnome"

It is easy to say things like "works for me and many other people" when you are not sitting at the receiving end of bugzilla and hearing complaints from those for whom it wasn't working well.

If you are someone who does not use 2-factor then you have to re-enter your password thrice -- once in GOA, once in EDS, once in Empathy. This sucks.

We have solved the problem for Empathy and 2-factor because we use OAuth2 tokens now. We used to use OAuth1 tokens before.

However, EDS (which uses Google Calendars via CalDAV) is still a problem. I know that Google is going to support OAuth2 over CalDAV, but the exact date is unclear. If that does not happen in time for 3.8, the other option is to write a GData based calendar backend for EDS. The Evolution developers are not too happy to write and maintain yet another vendor-specific backend (ie. GData), so maybe you can help them.
Comment 16 Debarshi Ray 2012-11-16 09:11:15 UTC
On second thoughts, maybe we should keep this bug open till this situation is resolved.
Comment 17 Ivan 2012-11-16 09:19:00 UTC
Come on man. I'm a software developer in trueconf.com company. And I'm receiving a lot of bugzilla updates every hour. I do not want to hurt you however I realy disappointed 3.6 update, that make me sit on gnome bugzilla instead of working comfortable as before. I really do not understand why the features working before stops working now. So it's not personal but professional fault to me and I'm sorry if it was too hard in text
Comment 18 Debarshi Ray 2012-11-16 10:10:32 UTC
(In reply to comment #17)
> Come on man. I'm a software developer in trueconf.com company. And I'm
> receiving a lot of bugzilla updates every hour.

My apologies if my words came across as harsh.

> instead of working comfortable as before. I really do not understand why the
> features working before stops working now. So it's not personal but
> professional fault to me and I'm sorry if it was too hard in text

To make things work smoothly for non-2-factor users we scrape the password from the web page and offer it to applications that need to work with Google services that do not use OAuth. Otherwise they have to re-enter their password in EDS and Empathy again, which sucks.

However, this breaks things for 2-factor users because they can not use the password that we offer, because we can not scrape the application specific password from the web page.

Also, GOA retries to verify that the credentials that it has for your account (ie. the OAuth token and the password in this case) are still valid. To check the password it uses the CalDAV endpoint. Since your normal password does not work in this case, and you need an application specific password it fails. This becomes an endless loop because your normal password will never work with 2-factor.

Since EDS throws a black system modal dialog at the user, it is hard for the user to enter their application specific password because it tends to be long and some people have it saved in an encrypted file on their computer. Even if we got rid of the black system modal, and replaced it with a normal dialog, things are still not as smooth as they could be. Also, that requires changes in EDS, so you will have to talk to the EDS folks.

Ideally someone has to write a GData calendar backend for EDS and things would work. But someone has to write the code and maintain it. You can be that someone.

Or we have to wait till Google makes OAuth2 support for CalDAV more widely available.
Comment 19 Nathan Bass 2012-11-19 18:57:09 UTC
I read the comments I understand we are really waiting at this point more than anything else but I wanted to go ahead and add a confirmation of sorts anyway:

https://bugs.archlinux.org/task/32761

The part I don't understand (I'm hoping Ivan or someone can elaborate for me) is the work around mentioned in Comment 10.

Generally I consider myself fairly capable in most things 'Nix' related but some things still puzzle me at least a bit (I was raised as a windoze {don't hold it against me ;) } user but I abandoned it years ago for anything other than my work), mainly related to hidden config files (give me something I can echo or cat to and I'll be happy, just not sure where to look ATM).
Comment 20 Debarshi Ray 2012-11-19 19:52:25 UTC
Use Seahorse to look at your keyring and try to locate the entry associated with your Google account. (Hint: You can put "GOA" in the search bar to filter the view to show only things stored by GOA.)

You will see that it has a dictionary. Locate the key called "password". Replace the value associated with that key with your application specific password.
Comment 21 Ivan 2012-11-20 03:20:38 UTC
(In reply to comment #20)
> Use Seahorse to look at your keyring and try to locate the entry associated
> with your Google account. (Hint: You can put "GOA" in the search bar to filter
> the view to show only things stored by GOA.)
> 
> You will see that it has a dictionary. Locate the key called "password".
> Replace the value associated with that key with your application specific
> password.

Yes. Check the show password, you'll see a long GOA_ string. At the end you'll see your google password. If you enable 2-factor auth and reproduces a bug, you should make an application password in google account and replace your google password in seahorse with it. Logoff and login again after solves the "expiration" problem
Comment 22 Nathan Bass 2012-11-20 05:36:09 UTC
Wonderful; that did indeed work. Thank you gentlemen for the assistance.
Comment 23 Debarshi Ray 2012-11-21 14:51:57 UTC
*** Bug 688773 has been marked as a duplicate of this bug. ***
Comment 24 jimmylc 2012-12-12 07:00:15 UTC
(In reply to comment #21)
> (In reply to comment #20)
> > Use Seahorse to look at your keyring and try to locate the entry associated
> > with your Google account. (Hint: You can put "GOA" in the search bar to filter
> > the view to show only things stored by GOA.)
> > 
> > You will see that it has a dictionary. Locate the key called "password".
> > Replace the value associated with that key with your application specific
> > password.
> 
> Yes. Check the show password, you'll see a long GOA_ string. At the end you'll
> see your google password. If you enable 2-factor auth and reproduces a bug, you
> should make an application password in google account and replace your google
> password in seahorse with it. Logoff and login again after solves the
> "expiration" problem

Excellent! this solution is working perfectly at least as a temporary solution, have been looking for days for this answer
Comment 25 Maciej (Matthew) Piechotka 2012-12-12 11:22:54 UTC
> (In reply to comment #12)
> 
> > find a way to make it works, so it's not so hard to ask an application
> > password.
> 
> It is hard to ask for an application password without screwing up the whole UX
> for everybody -- including non-2-factor users.
> 

Maybe the simplest way of implementing 2-factor auth in Gnome is to do something similar to chrome/ium (I'm not sure  about actual implementation):

 - Give use log in dialog as previously
 - Allow user to log in using main password, get OAUTH token, save password
 - Optionally: Verify that token works
 - Check if password works. If it does not than say something "It looks like you use 2-factor authentication. You need to enter application-specific password as well" and provide input for password(In reply to comment #13)
Comment 26 Patryk Zawadzki 2012-12-12 11:26:13 UTC
I'd rather not have GNOME attempt man-in-the-middle password sniffing attacks at all. Please don't sacrifice trust in the name of convenience.
Comment 27 Martin Dengler 2013-01-31 23:47:47 UTC
(In reply to comment #26)
> I'd rather not have GNOME attempt man-in-the-middle password sniffing attacks
> at all. Please don't sacrifice trust in the name of convenience.

I'm not sure it's helpful to straw-man #25 as "a password-sniffing attack".  Dramatics sounds as bad coming from a developer as "XXX other big project can hack it, why don't you" from users.
Comment 28 Martin Dengler 2013-01-31 23:49:01 UTC
(In reply to comment #25)
>  - Check if password works. If it does not than say something "It looks like
> you use 2-factor authentication. You need to enter application-specific
> password as well" and provide input for password

If you can give me a "hack this" pointer to a file in a git repo, I can have a go.  It might be enough just to make this bug report a bit more google-able.  Using an app-specific password certainly worked for me.
Comment 29 Patryk Zawadzki 2013-02-01 10:31:07 UTC
(In reply to comment #27)
> I'm not sure it's helpful to straw-man #25 as "a password-sniffing attack". 
> Dramatics sounds as bad coming from a developer as "XXX other big project can
> hack it, why don't you" from users.

I don't believe it's a strawman argument. It's an unwritten contract of trust that my user agent does not save any passwords without me explicitly allowing it to. Especially so over secure connections and for fields with autocomplete="off". Especially so for use outside of the scope the password was originally entered in (the login form on the website).

How would it make you feel if a piece of software offered you a paid upgrade, displayed an embedded PayPal window and then decided it would be nifty to intercept and save your PayPal password without you knowing? For me that is a breach of the unwritten contract.

If you need a password, ask for it explicitly. Even if I have to retype it.
Comment 30 Maciej (Matthew) Piechotka 2013-02-01 12:01:07 UTC
(In reply to comment #29)
> (In reply to comment #27)
> > I'm not sure it's helpful to straw-man #25 as "a password-sniffing attack". 
> > Dramatics sounds as bad coming from a developer as "XXX other big project can
> > hack it, why don't you" from users.
> 
> I don't believe it's a strawman argument. It's an unwritten contract of trust
> that my user agent does not save any passwords without me explicitly allowing
> it to. Especially so over secure connections and for fields with
> autocomplete="off". Especially so for use outside of the scope the password was
> originally entered in (the login form on the website).
> 
> How would it make you feel if a piece of software offered you a paid upgrade,
> displayed an embedded PayPal window and then decided it would be nifty to
> intercept and save your PayPal password without you knowing? For me that is a
> breach of the unwritten contract.
> 
> If you need a password, ask for it explicitly. Even if I have to retype it.

While I see your point it is a dialog box explicitly for adding the account to system. I believe it is explicit by unwritten rules that it saves some information which allows the client to connect to server at any time (at least - the same assumption is made in Android, Windows 8, IOS etc.) - you can still log in each time just by adding account in application and requesting it not to save password. On the other hand the example you have given there is no such unwritten contract. It is not 'add PayPal account' but 'log into PayPal account' hence implying one-time use of the account. And presence in system settings instead of application settings implies that it affect system-wise instead of application-wise.

The only possible worrisome element is user might think that only OAUTH token is saved and not the password itself (not using OAUTH token from what I understand is lack of support on Google side not Gnome side).
Comment 31 Patryk Zawadzki 2013-02-01 12:19:52 UTC
(In reply to comment #30)
> The only possible worrisome element is user might think that only OAUTH token
> is saved and not the password itself (not using OAUTH token from what I
> understand is lack of support on Google side not Gnome side).

That's the whole point. OAUTH provides a simple, revokable way to grant an application limited access to your account. On the other hand giving an app access to your master password gives it unrevokable and unlimited access to everything you can do as the application is therefore able to act as the owner of the account.

To make things worse, gnome-online-accounts also breaks the per-application part of the OAUTH protocol as it effectively makes the whole desktop a single application. I would much rather have it act as an OAUTH mediator that apps can use to request a *private* OAUTH key so in the end the Flickr app is not able to delete your Google documents (even if its author swears that it would never do that).
Comment 32 Mantas Mikulėnas (grawity) 2013-02-01 13:01:15 UTC
(In reply to comment #31)
> (In reply to comment #30)
> > The only possible worrisome element is user might think that only OAUTH token
> > is saved and not the password itself (not using OAUTH token from what I
> > understand is lack of support on Google side not Gnome side).
> 
> That's the whole point. OAUTH provides a simple, revokable way to grant an
> application limited access to your account. On the other hand giving an app
> access to your master password gives it unrevokable and unlimited access to
> everything you can do as the application is therefore able to act as the owner
> of the account.

I thought the only reason GNOME stores the password is that not all Google protocols support OAuth yet?
Comment 33 Debarshi Ray 2013-02-11 13:39:54 UTC
Saving the password does not necessarily mean that it is a man in the middle attack. That would be an exaggeration. The password is stored in the encypted keyring as any other secret and not a plain text file. When you add an account using the Online Accounts panel it means you are giving access to GNOME (ie. all core components of GNOME), and not just a single application. If you are not comfortable with doing that, then don't add your account.

Even if only used OAuth2, even then you are granting GNOME the permission to access your account and data, and it can potentially impersonate you or tamper your data. So unless you trust GNOME, you should not be adding your account.

It is technically impossible to limit the access to a single application because we don't have any sandboxing facility. Any application is free to read the OAuth2 token or whatever secret you use, no matter what you do. Once we have a sandbox it will be possible to impose such restrictions on applications.

A password is used because of the way Evolution Data Server interacts with Google Calendar. Currently it fails to use a OAuth2 token, and since it throws a system modal dialog asking for the password, it is hard for people to supply an application-specific password, which is typically too long to be memorized.

The correct fix is to implement a backend for EDS that can work with Google Calendars using OAuth2 tokens. See bug 686804

Either subscribe to the EDS bug or provide a patch. Just piling on comments on this bug will not magically solve anything. :-)
Comment 34 Debarshi Ray 2013-03-02 21:01:38 UTC
*** Bug 694996 has been marked as a duplicate of this bug. ***
Comment 35 Jonathan 2013-03-07 23:11:46 UTC
Adding an app specific password in seahorse made contacts and mail work but calendar is still broken for me.
Comment 36 Jonathan 2013-03-09 10:21:36 UTC
Correcting myself, calendar is now also working. Waiting a day autofixed it...
I don't understand why but as it is working, I'm happy.

To give you a sense of purpose, google 2-factor and integration into gnome is the feature that convinced me into upgrading my gnome system, thank you for this great feature!
Comment 37 Harald Glatt (hachre) 2013-03-22 22:39:06 UTC
The original comments explaining what was happening said that only Calendar and GTalk are affected. But Contacts doesn't work for me either. Neither does Google Drive in Documents. Is that expected? I also tried it in Gnome 2.7.92 and none of these things work there either. 

I think at the very least we need to introduce a message to the user saying "2-factor isn't supported" when detected and a fallback to an application specific password should be supported and provided in any case.
Comment 38 Harald Glatt (hachre) 2013-03-22 22:40:57 UTC
Sorry, I meant Gnome 3.7.92 of course.
Comment 39 Adrian Wyssmann 2013-04-16 20:21:12 UTC
Wow, still not fixed? I'd actually like to use GOA but if I have to disable 2-step verification, this is a no-go
Comment 40 Ivan 2013-04-17 03:26:10 UTC
probably it's not so secure as it seems, and may be it's a good luck they does not fix it at all ;)

http://nelenkov.blogspot.ru/2012/11/sso-using-account-manager.html
Comment 41 spam.moreplz 2013-04-27 11:50:49 UTC
Gnome Shell 3.8
Two factor authentication

login with Google username and password, enter verification code
password expires instantly.

Workaround:
open seahorse, find goa, replace password with generated one time password.

Seems fixed
Comment 42 Ariel 2013-05-10 23:17:01 UTC
same issue - same solution as comment 41. the only comment: instead of replacing the whole text in the password field of seahorse, edit the field, there are many attributes in there besides the password - and just replace the password field. After that, I logged out and back in and voila, it worked. Empathy and Documents working fine now.
Comment 44 Debarshi Ray 2013-06-27 14:16:32 UTC
This is blocking on evolution-data-server (see bug 686804). EDS needs to implement authenticating to CalDAV using OAuth2. There is nothing left to do in GOA apart from deleting the raw password sniffing code.
Comment 45 Debarshi Ray 2013-07-12 14:19:59 UTC
Closing.

In case someone wants to test, you need gnome-online-accounts-3.9.4 and evolution-data-server-3.9.5 (ie. Git master at this moment).
Comment 46 Debarshi Ray 2013-08-21 11:09:27 UTC
*** Bug 706473 has been marked as a duplicate of this bug. ***
Comment 47 Debarshi Ray 2013-09-12 12:02:34 UTC
*** Bug 707965 has been marked as a duplicate of this bug. ***
Comment 48 Debarshi Ray 2013-09-12 12:40:34 UTC
*** Bug 707969 has been marked as a duplicate of this bug. ***