Google phasing out less secure access

[Eduardo Mercovich]

Hello everyone.

Probably many of you already received this message from Google:

> To help keep your account secure, Google will no longer support the
> use of third-party apps or devices which ask you to sign in to your
> Google Account using only your username and password. Instead, you’ll
> need to sign in using Sign in with Google or other more secure
> technologies, like OAuth 2.0.

Since many of us sync one (or more) google accounts to our beloved
maildir with mu4e (well, really with isync or something similar, but we
read it and write with mu4e), these may be a serious problem.

I didn't found many references to this issue using different
combinations of "google may 30 OAuth 2.0 +(mbsync OR isync)", so I'd
like to know if/how you are approaching this deadline.

Of course, this is not specific about mu4e, but since many of use share
the same maildir sync mechanism, I thought it may be ok to ask here. If
it's not, sorry and I'll search in other places.

As always, thanks a lot for your dedication, sharing and attention. :)

Best regards...


--
Eduardo Mercovich

Donde se cruzan tus talentos
con las necesidades del mundo,
ahí está tu vocación.
(Anónimo)

[Daniel Fleischer]

Eduardo Mercovich [2022-04-29 Fri 18:56] wrote:

> Since many of us sync one (or more) google accounts to our beloved
> maildir with mu4e (well, really with isync or something similar, but we
> read it and write with mu4e), these may be a serious problem.

My understanding is that there isn't ans issue if you use 2FA. You then
use an app-specific password (e.g. and put it in authinfo) and that's
it; there is no change to that workflow. It's a way to push people
towards more secure methods, including 2FA.

So again, if you have 2FA and generated an app-password, you're good.
This is about phasing out older authentication methods.

Best,

--

Daniel Fleischer

[Tim Cross]

Unfortunately, Google is phasing out the application passwords as well, so you won't be OK even with 2FA. 

Apparently you can get Emacs to use oauth2, so it should be OK for sending (smtp). I also believe you might be able to get mbsync to work with oauth2, but I have no details on that. Likely what you will need to do is first sign-in via the web, get the oath2 toien and use that like a password until it expires and then go through the process again. 

Not that MS has also flagged they are going to do similar. 

At some point, it will be necessary to find a sync solution which can use oath2 or forward your mail to a different provider which does support username/passwords.

--
You received this message because you are subscribed to the Google Groups "mu-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mu-discuss+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mu-discuss/m2fslvgdcb.fsf%40gmail.com.

--

regards,

Tim

--

Tim Cross

[Daniel Fleischer]

Tim Cross [2022-05-03 Tue 02:30] wrote:

> Unfortunately, Google is phasing out the application passwords as
> well, so you won't be OK even with 2FA.

Thanks, that wasn't my understanding and I'll be happy to learn more
about this.

[Eduardo Mercovich]

Hi Tim and Daniel.

> Unfortunately, Google is phasing out the application passwords as well, so you
> won't be OK even with 2FA.

Ouch, it looked so simple it couldn't be true... ;P

> Apparently you can get Emacs to use oauth2 [...]

I searched that and it seems it's not easy. A few mentions but not super
complete... I will keep searching a bit and share the articles.

> Likely what you will need to do is first sign-in via
> the web, get the oath2 toien and use that like a password until it expires and
> then go through the process again.

:(

> Not that MS has also flagged they are going to do similar.

Happily I don't have anything there, but bad luck also for those that
have clients that choose that platform...

> At some point, it will be necessary to find a sync solution which can use oath2
> or forward your mail to a different provider which does support
> username/passwords.

Yes, this would be great.
Actually, at the mbsync level...

[Tim Cross]

Interesting. I just tried to find the announcement from Google where
they said app specific passwords for imap/smtp were going to be removed
and now cannot find it. Google originally said they were going to remove
all password based access and only support oauth2 by mid 2021. This was
later postponed due to the pandemic.

There were some lengthy threads about this in emacs-devel i late 2020
and early 2021.

Looking at what Google currently has up, it seems they are now
suggesting that if you have to use applicaitons which don't support
oath2, you can use an app password.

Due to Google's policy regarding oauth2 apps needing to be vetted by
Google and the requirement that any oaht2 toeksn not being visible to
end users, there was a real issue for open source applications wanting
to support oauth2. With oauth2, you have an application 'token'
(misleadingly called a secret in oath2 terminology), which is used to
identify a specific application. The idea being, if google foudn a
specific application had a vulnerability, it could lock out just that
application easily/quickly.

There are 2 ways to get an application token. The main way is to have
your application registered with google (think mbsync for example). The
other way is to register as a developer and get a developer app toeken
(anyone can do this, but it is a bit of a pain). The problem for open
source software is that they cannot embed the application token in the
source code as it has to remain a secret to comply with Google's T&C.

My guess is that Google has perhaps decided to leave app passwords in
place as a work-around for open source apps - at least for the time
being.

The threads on emacs-devel had some details on how to setup smtp and
oauth2 and there was some sketchy details on how you could use mbsync
and other prorams, provided they were built with SASL support.

I believe some applications, like possibly Thunderbird and Mutt, have
ignored the Google T&C and have put an application token into their code
in order to have it work without the need for app passwords. I've not
verified this.

The other solution mentioned in the emacs-devel threads was to use a
proxy service i.e. davMail as a gateway. This can work well if you need
to access both gmail and office365.

[George Clemmer]

Tim Cross <theop...@gmail.com> writes:

> Unfortunately, Google is phasing out the application passwords as well, so
> you won't be OK even with 2FA.

Do you know when this will happen?
TIA - George

[Eduardo Mercovich]

Hi Tim.

> [...] Looking at what Google currently has up, it seems they are now

> suggesting that if you have to use applicaitons which don't support
> oath2, you can use an app password.

> Due to Google's policy regarding oauth2 apps needing to be vetted by
> Google and the requirement that any oaht2 toeksn not being visible to
> end users, there was a real issue for open source applications wanting

> to support oauth2. [...] My guess is that Google has perhaps decided

> to leave app passwords in place as a work-around for open source apps
> - at least for the time being.

Thanks for the clear explanation.
This may become a real problem for the FLOSS ecosystem...

> The threads on emacs-devel had some details on how to setup smtp and
> oauth2 and there was some sketchy details on how you could use mbsync
> and other prorams, provided they were built with SASL support.

Did you saw this working somewhere?

> [...] The other solution mentioned in the emacs-devel threads was to

> use a proxy service i.e. davMail as a gateway. This can work well if
> you need to access both gmail and office365.

This seems interesting. It suggests also a similar, local way to do
this: a locally installed piece of software that can make a gate between
others (like mbsync) and Google that will require a key, but as you said
anyone can register a get a key.

But I'm no programmer and so this it may be a non-idea... ;P

[Tim Cross]

Not sure they are now. In the original announcement in 2018/2019, they
indicated they were removing all password based access. However,
it now seems they are only talking about removing the ability to use
your 'normal' google password and now suggest using application
passwords if your client doesn't support oauth2.

[Norm Tovey-Walsh]

Eduardo Mercovich <eduardo....@gmail.com> writes:
>> [...] The other solution mentioned in the emacs-devel threads was to
>> use a proxy service i.e. davMail as a gateway. This can work well if
>> you need to access both gmail and office365.

At a previous $EMPLOYER, I had to use the Exchange protocol for work
email. It was a bit fiddly to setup, but DavMail did the job very
nicely. I’m not aware that it also does OAuth for Gmail, but perhaps it
does. Current $EMPLOYER doesn’t require Exchange so I’ve happily gone
back to a simpler setup. And I migrated from GMail to FastMail a while
back.

Be seeing you,
norm

--
Norman Tovey-Walsh <n...@nwalsh.com>
https://nwalsh.com/

> Ahhh. A man with a sharp wit. Someone ought to take it away from him
> before he cuts himself.--Peter da Silva

[Eduardo Mercovich]

Hi Norm.

>>> [...] The other solution mentioned in the emacs-devel threads was to
>>> use a proxy service i.e. davMail as a gateway. This can work well if
>>> you need to access both gmail and office365.

> [...] DavMail did the job very nicely. I’m not aware that it also does

> OAuth for Gmail, but perhaps it does.

There is no mention in Davmail docs (http://davmail.sourceforge.net/)
From what I read in
http://blog.nacimientohernan.com.ar/2017/07/davmail-proxy-para-gmail.html
it seems so...

> Current $EMPLOYER doesn’t require Exchange so I’ve happily gone
> back to a simpler setup. And I migrated from GMail to FastMail a while
> back.

I would love to completely degoogle myself (and my personal mail and
files are outside google), but many other people still uses google
services and that's why I still need 1 google account, to access
documents... sad situation but still true.

However, let's see if I got it ok. The possible chain would be:

Gmail (cloud) > Davmail (local) > mbsync (local)

Is this what you had in mind?

[Tim Cross]

Eduardo Mercovich <eduardo....@gmail.com> writes:

> Hi Norm.
>
>>>> [...] The other solution mentioned in the emacs-devel threads was to
>>>> use a proxy service i.e. davMail as a gateway. This can work well if
>>>> you need to access both gmail and office365.
>
>> [...] DavMail did the job very nicely. I’m not aware that it also does
>> OAuth for Gmail, but perhaps it does.
>
> There is no mention in Davmail docs (http://davmail.sourceforge.net/)
> From what I read in
> http://blog.nacimientohernan.com.ar/2017/07/davmail-proxy-para-gmail.html
> it seems so... > Current $EMPLOYER doesn’t require Exchange so I’ve happily gone
>> back to a simpler setup. And I migrated from GMail to FastMail a while
>> back.
>
> I would love to completely degoogle myself (and my personal mail and
> files are outside google), but many other people still uses google
> services and that's why I still need 1 google account, to access
> documents... sad situation but still true. However, let's see if I got it ok.
> The possible chain would be:
>
> Gmail (cloud) > Davmail (local) > mbsync (local)
>
> Is this what you had in mind?

As it looks like google will NOT remove app passwords anytime soon, I
would just use them and avoid all the extra work setting up and
maintaining davmail. If an when they do remove app passwords, it is
likely utilities like mbsync will be able to work with Googles oauth2
service.

[Eduardo Mercovich]

Hi!

>> Gmail (cloud) > Davmail (local) > mbsync (local)
>> Is this what you had in mind?

> As it looks like google will NOT remove app passwords anytime soon, I
> would just use them and avoid all the extra work setting up and
> maintaining davmail.

I'm on the same boat comrade. :)

> If an when they do remove app passwords, it is likely utilities like
> mbsync will be able to work with Googles oauth2 service.

I hope so. However, I recognize I'd be happier if that starts sooner
than later...

Warm regards.

[Norm Tovey-Walsh]

> I would love to completely degoogle myself (and my personal mail and
> files are outside google), but many other people still uses google
> services and that's why I still need 1 google account, to access
> documents... sad situation but still true. However, let's see if I got
> it ok. The possible chain would be:

To be fair, I still have a Google identity as well, but I never used it
as a public email address, so migrating email off gmail wasn’t too hard.

> Gmail (cloud) > Davmail (local) > mbsync (local)
>
> Is this what you had in mind?

Yes, something like that. Not sure what’s in-the-middle for GMail, but

Exchange > Davmail (local) > mbsync (local)

worked for me.

Be seeing you,
norm

--
Norman Tovey-Walsh <n...@nwalsh.com>
https://nwalsh.com/

> I'd love to change the world, but I can't figure out how to checkout
> the source code.

[Eduardo Mercovich]

Hi Norm.

[...]

>> Gmail (cloud) > Davmail (local) > mbsync (local)
>> Is this what you had in mind?

> Yes, something like that. Not sure what’s in-the-middle for GMail, but
> Exchange > Davmail (local) > mbsync (local)
> worked for me.

Great, thanks a lot. I may be a good way...

As for now, migrate to specific app-password any remaining account seems
to be a wise move.

Thanks a lot, and best regards. :)