Cannot login to Google account

[ghost]

I have been forwarded here from this bug report about Kopete:

https://bugs.kde.org/show_bug.cgi?id=354473

The actual message that sent me here is:

Anyway, Kopete for jabber connection (and also this authentication!) uses external libiris library. So I cannot fix this problem in Kopete. It would mean to implemented either X-OAUTH2 or X-GOOGLE-TOKEN in libiris. So please report this problem to upstream libiris project. Now when we know that this is 100% not in Kopete, I will close this bug as cannot do more. Project page of libiris is: https://github.com/psi-im/iris

I hope you can look into this.

[wadealer]

There is no problem to connect to Google account with iris. I do this every day with Psi. But you should enable connection with untrusted applications at your Google account settings. This can be done at this page https://myaccount.google.com/security

[Ri0n]

I don't think we have to implement X-OAUTH2 or X-GOOGLE-TOKEN in libiris. These are kind of dying methods for XMPP. But I could implement some mechanism to extend libiris auth capabilities. I think it's fine to implement X-OAUTH2 as a plugin for example.

[ghost]

But why should I reduce the overall security of my account just to be able to use Kopete or other app using iris? Pidgin works with full encryption without having to make this. For Kopete I have to use plaintext authentication and set Allow less secure apps to ON. I don't see why this should be appropriate or a solution at all. I hope you understand.

[pali]

Just one important thing: I do not see any reason from security point of view why to implement such auth menthod for google. Google bitching because plain text auth is less secure and bla bla bla... But still majority of users login to Gmail via web with plain text passwords. So why to use something else for Jabber? And reason to enable "untrusted applications" settings? Google just decided which applications are trusted and which untrusted? Surely this is not how you decide which application are secure and which not...

[ghost]

But still majority of users login to Gmail via web with plain text passwords.

I don't see how that would be possible considering that all Gmail web works on SSL which practically means nobody can use Gmail without encryption. So I don't understand what is the 'majority of users'.

The issue I am reporting is that the only way to use Kopete with Google is to use plain text authentication and set Allow less secure apps to ON.

[pali]

Because password entered in web broeser is sent as plaintext in TLS tunnel. Exactly same what is doing jabber client (when SCRAM is not supported).

By majority of users I mean all normal google users without own domain/organization. Google for organizations support external authenication method (via some SAML protocol).

[ghost]

pali

I actually use Google Apps for business (with own domain) and I also use 2-step verification.

What do you suggest to do?

[pali]

Security suggestion would be to tell google to implement standard secure jabber authentication method e.g. SCRAM-SHA256. IIRC SAML (which is used by google for organization/business) is not supported by jabber protocol and therfore you cannot use it...

[ghost]

All right. Let's say the problem is in Google: How does Pidgin work without problems and with encryption, and without having to reduce account security?

[pali]

It is already in first post, using non standard auth method X-OAUTH2 or X-GOOGLE-TOKEN.

[ghost]

So I guess my only option is to wait for X-OAUTH2 to be implemented as plugin or?

[pali]

That is up to @Ri0n or @wadealer if they accept/implemenet such "dying methods for XMPP"...

[ghost]

Ok. Thanks.

[Ri0n]

Well I actually already hacked iris to support external authenticators. and oauth2 is half-finished. But I will not commit oauth2 stuff to Psi. It's just a proof of concept.

[pali]

@Ri0n So would you add oauth2 (maybe just optional) support to iris? Or do you plan to somehow support external auth methods?

[Ri0n]

external. actually I don't like it all since it does not comply with xmpp standards

[Ri0n]

My external auth hacks work.

<!-- TS:2016-03-20T21:56:09--><auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="X-OAUTH2">AHJMaskedSecretHashFJBcVE0eDdUWUE=</auth>

<!-- TS:2016-03-20T21:56:09--><success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>

What I did

1. Register new QCA sasl provider
2. Register our provider for ClientStream like AUTH_METHOD => PROVIDER_NAME
3. If server methods contains at least one our AUTH_METHOD then forget about other providers and use ours.

I'm still not quite happy with it since SASL doesn't know anything about OAuth2 specific stuff like auth/refresh tokens and permission requests.

[pali]

Yes, for connecting you need to specify: request url, client id, client secret key and refresh token. All these instead things instead one password. From security point of view it does not bring any value. Anybody with knowledge of those "strings" can login same as if he would know password. If you think that it brings security in ability with revoking client secret key or refresh token, do not forget that you can revoke/change also password...

Or you can change above tuple of "ids" by one access token which is valid for one hour. But that would mean that user who wants to login will need to generate that access token externally every time he wants to login and (probably) also generate new every hour...

I can imagine that I could add new option in Kopete account settings dialog where user enter that 4 ids for oauth2 login. But that would be only for super-power-users who are able to generate those ids from his oauth2 provider.

There is still no standardized way how to generate refresh tokens (e.g. google via api send you URL for web page where you need to do some actions) on client side (nor in jabber protocol) and also there is no way to generate client id and secret key automated.

So... from my point of view: Iris is library for xmpp protocol which also need to do authentication. Normally I tell iris two strings "username" and "password" and it do authentication. For oauth2 I need to tell iris for another strings instead "password". Maybe in future there will be another authentication mechanisms which will use another set of strings/ids/tokens. What about extending iris, so caller would be able to tell his authentication strings (e.g. QHash) and then authentication code (maybe internal or external plugin) will take those authentication strings and do what that auth method needs? E.g. there is GSS-API/Kerberos authentication method for jabber and for such thing (if you want to implement it one day) you need to tell your prinicipal, tiket id, keytab file or maybe krb5 provider. I think that uniform list/hash of key/value parameters could work...

[Ri0n]

Here is demo for Psi https://github.com/psi-plus/main/blob/master/patches/dev/xoauth2-support-demo.diff I have not plans for further development of this feature. It's ugly and incomplete. Don't blame me, I just don't like it.

[pali]

I see that you hardcoded and published your oauth2 client secret key. This is probably not how it should be used and so proper way would be to ask user to enter his secret key and provide it to that xoauth2 mechanism code...

[pali]

I will try to play with it in Kopete... support for custom providers in iris now should be enough, so thanks!

[Ri0n]

About client secret... I received this key after long and exhausting registration procedure of my client (Psi+) on google service. It's not user's responsibility IMO. I don't know why it has "secret" in name. It definitely should be distributed with client.

[pali]

Client secret is secret and confidential. It must be secured against other usage as in that application. Client secret key is there for application authorization. When is misused (e.g. used in other application), client secret key should be revoked. So you cannot really disclose it. Obviously you cannot include it in open source application. And so it must be stored out of open source code/application.

Also you must use client secret key only if you can secure that it will not leak. If you are not able then you should not use it (and instead to http basic authentication)...

Now I see that OAUTH2 is "defined" in RFC6749: https://tools.ietf.org/html/rfc6749 I will try to read it properly, but looks like it does not define lot of things...

[Ri0n]

Good luck!

[Massimo-B]

Following this thread I understand that xoauth2 does not offer more security. However in the Google Account it is useful to see the applications actually connecting to the account, instead of just "Linux". But on the other side I don't see my IMAPS client either connecting to the Google Mail service.

[pali]

@Ri0n I used your demo to implement X-OAuth2 in Kopete properly. That you very much for custom sasl provider support in libiris. Code for Kopete is prepared: https://git.reviewboard.kde.org/r/129239/

[Ri0n]

Just took a look on the review. Looks incredibly complicated..

UPD: I mean instruction for user.

[pali]

Seems that KDE admins removed instructions from above webpage (it does not work anymore), so here is copy of them: https://www.mail-archive.com/kopete-devel@kde.org/msg17537.html