6 ms·

The sign-in method they're removing really is less secure: you're sending your full username and password to a third-party. Application-specific passwords (htt

by jefftk 5y ago

The sign-in method they're removing really is less secure: you're sending your full username and password to a third-party. Application-specific passwords (https://support.google.com/accounts/answer/185833 https://support.google.com/accounts/answer/185833) and OAuth are much better. Disclosure: I work for Google, speaking only for myself

samtheDamned 5y ago
I agree, I have always hated having to give my google credentials to random apps instead of just using something like oauth where I can be more confident in the security of my credentials.
Wowfunhappy 5y ago
An email client running on my own machine is not a third party. But regardless, this is why the feature is called "enable access for less secure apps". It's disabled by default, and it re-disables itself automatically unless you're actively using it to sign in. My Google account does not contain nuclear launch codes, and my threat model is not the same as Google's. I am far more worried about getting locked out of my own account due to some mishap than I am someone else getting in, and I think I should be able to assess my own risk. Google can set defaults, but I know my own life. (I will say that I wouldn't mind switching to app-specific passwords, but Google won't let me because I have 2FA turned off. I don't want 2FA because I don't want to get locked out of my account, I don't need 2FA because I use a password manager, and I don't understand how 2FA and app-specific passwords are related.)
- jefftk 5y ago
  I do think you're right about 2FA, and there should be an option to use an application specific password without 2FA.
- ASalazarMX 5y ago
  FWIW, 2FA is very low friction. You'll get a "Is this you?" popup in your phone or tablet whenever someone uses your username and password in a new device/browser/application. If it wasn't you, then someone else besides you knows your credentials and you need to change them ASAP. If it was you, you have another 2FA point. Also, I enabled 2FA a couple of years ago, and have been happily using app-specific passwords ("app passwords" now) since they were implemented. Tying them to 2FA activation doesn't look like an engineering limitation.
  - Wowfunhappy 5y ago
    > You'll get a "Is this you?" popup in your phone or tablet whenever someone uses your username and password in a new device/browser/application. I have two different concerns. The first is that I frequently end up having to clear my browser cookies, for a variety of reasons. Every time I do, I have to redo the 2FA dance, on every single website that requires 2FA. I suppose I could find a different cookie management strategy, but I think it's good for both privacy and security to treat cookies as semi-ephemeral. Secondly, I’m concerned that I'll either loose or replace my 2FA device and forget about the account until it's too late—again, I’m much more concerned about losing access to my account than someone else getting in. I would almost certainly loose any physical backup codes. I also have a fantasy that I'll give up my smartphone one of these days, or at least not bring it everywhere I go. I’ll probably never do it, but the idea is such that I don't want to depend on an app for access to my account. I do think I’ve successfully made myself less dependent on my smartphone than a lot of people, and I’m proud of that accomplishment.
    - ThePowerOfFuet 5y ago
      Then try TOTP, and back up your seeds.
    - rolandog 5y ago
      Have you thought about multiple 2FA devices? To my knowledge, you can use as 2FA w/Google: 1. A prompt on your phone 2. A hardware security key 3. TOTP token from authenticator 4. one of 10 backup codes And you can also have multiple security keys as well, which is useful if you lose one.
      - Wowfunhappy 5y ago
        A prompt on my phone and an app on my phone come down to the same thing, and I'm not interested in getting a physical hardware security key. The backup codes are one-time use, and there is no way I would keep track of a slip of paper for years without loosing it. I could use my password manager (Bitwarden) as my TOTP generator, and I may eventually do that just to make all of these services shut up. But, wouldn't that leave my account no more secure than it already is today? It would effectively be single-factor authentication, since the password and the generator would be in the same place, protected by the same master password.
prophesi 5y ago
Sweet, I was about to look into whether I'd need to make changes to my OAuth integration. Makes sense that it's fine since the username/password (or however they wish to authenticate) is sent to Google themselves.
folmar 5y ago
There are still non-web applications, so no, that's not a third party. If I save my credentials in Mutt/Pine it's more secure than entering them in the browser - much less attack surface, and not more third party than a browser. There are some benefits to having a token like in oauth, for example simple way to revoke some sessions access, but it's a tradeoff, not black and white.
michaelmrose 5y ago
You aren't necessarily actually sending it to a third party per se though. Less secure access also enables using software running on your own computer to access your email easily. For example offlineimap and imapfilter. In theory it ought to work with OAuth but damned if I can get it to work and any instructions a few years old are useless because something has changed in the interim. It's actually less hassle to migrate off Gmail. Quite frankly there are few Google things that at this point aren't a hassle to work with. Google is poised to ruin adblocking in chrome with manifest v3, search is increasingly polluted by junk, gmail is now a pain to work with outside of a web browser and awful to use in a web browser, the play store is so bad as far as finding non junk non malware that its necessary to use an outside web page like say bing/duck duck go to find apps to install with play store which serves at best as an updater interface, workspace is a pain. Various actually useful services like reader picasa google+ are dead. The only remaining useful end user services are youtube, maps, and android. As someone who used to be excited about Google stuff its kind of disappointing. Gmail user from June 2004-2022 but soon no longer. Thanks for 18 years of good service for the absolutely ridiculously low price of I think $80 to date.
- jefftk 5y ago
  > Less secure access also enables using software running on your own computer to access your email easily. For example offlineimap and imapfilter. In theory it ought to work with OAuth but damned if I can get it to work and any instructions a few years old are useless because something has changed in the interim. You shouldn't need OAuth; have you tried application-specific passwords (https://support.google.com/accounts/answer/185833 https://support.google.com/accounts/answer/185833)?
  - michaelmrose 5y ago
    If this is an effective workaround why is it useful to disable the feature in the first place. It seems like a 16 digit password this is actually much less secure than the current state of affairs. It's probably not much worth exploring because I'm also having to migrate off of legacy google apps for your domain as well.
  - 5y ago
dcow 5y ago
I really think Google needs to make a distinction between sending your credentials to a foreign 3rd party service/domain vs a “3rd party” client that runs on your machine. Sending your credentials somewhere else is understandably best avoided. Using a different “3rd party” user agent than the top 3 browsers to access some google services, on the other hand, really isn’t less secure at all and I even think an argument could be made that it’s more secure than a browser in many cases. Local (wouldn't even mind if it was limited to open source) apps should be given unrestricted access to the Gmail OAuth scopes. Until then, I can’t see how this is anything other than a platform control play under the guise of user safety to lock down API access to blessed google clients and services.
- jefftk 5y ago
  > Local (wouldn't even mind if it was limited to open source) apps How could a rule like that be enforced? > lock down API access to blessed google clients and services. What's wrong with application specific passwords? (Still speaking only for myself)
  - dcow 5y ago
    > How could a rule like that be enforced? Considering the review process is currently subjective, then subjectively I guess. If you say in the review that you're an open source app and that you only do native OAuth locally then you get approval. Google already requires a link to your project's homepage maybe additionally you have to provide one to your source code so the reviewers can verify. If you prove to be untrustworthy and in violation at some point in the future then your access gets pulled. Maybe the problem is that google is trying to enforce client behavior in the first place? I thought the point of OAuth was that the user gets to approve or deny access to granularly scoped resources on their account, not google.
  - dcow 5y ago
    Re app passwords: aren't you still a "less secure app" then? Really it's the messaging https://support.google.com/accounts/answer/185833?hl=en https://support.google.com/accounts/answer/185833?hl=en: > Tip: App Passwords aren’t recommended and are unnecessary in most cases. To help keep your account secure, use "Sign in with Google" to connect apps to your Google Account. > > An App Password is a 16-digit passcode that gives a less secure app or device permission to access your Google Account. App Passwords can only be used with accounts that have 2-Step Verification turned on. So e.g. I'm trying to build a "more secure" app that uses sign-in with google like it's supposed to and Google says "sorry your use case isn't approved". My recourse is just be a less secure app? Isn't that a little unfair? More-so, according to google's messaging, doesn't that make the user less secure?
yoavm 5y ago
Sometimes you can't use OAuth because your client doesn't support it. If you ever run into that problem you might find my project useful - OAuth Hopper serves as a simple proxy that removes OAuth from services. github.com/bjesus/oauth-hopper/

by jefftk 5y ago

samtheDamned 5y ago

I agree, I have always hated having to give my google credentials to random apps instead of just using something like oauth where I can be more confident in the security of my credentials.

Wowfunhappy 5y ago

An email client running on my own machine is not a third party. But regardless, this is why the feature is called "enable access for less secure apps". It's disabled by default, and it re-disables itself automatically unless you're actively using it to sign in. My Google account does not contain nuclear launch codes, and my threat model is not the same as Google's. I am far more worried about getting locked out of my own account due to some mishap than I am someone else getting in, and I think I should be able to assess my own risk. Google can set defaults, but I know my own life. (I will say that I wouldn't mind switching to app-specific passwords, but Google won't let me because I have 2FA turned off. I don't want 2FA because I don't want to get locked out of my account, I don't need 2FA because I use a password manager, and I don't understand how 2FA and app-specific passwords are related.)

jefftk 5y ago
I do think you're right about 2FA, and there should be an option to use an application specific password without 2FA.
ASalazarMX 5y ago
FWIW, 2FA is very low friction. You'll get a "Is this you?" popup in your phone or tablet whenever someone uses your username and password in a new device/browser/application. If it wasn't you, then someone else besides you knows your credentials and you need to change them ASAP. If it was you, you have another 2FA point. Also, I enabled 2FA a couple of years ago, and have been happily using app-specific passwords ("app passwords" now) since they were implemented. Tying them to 2FA activation doesn't look like an engineering limitation.
- Wowfunhappy 5y ago
  > You'll get a "Is this you?" popup in your phone or tablet whenever someone uses your username and password in a new device/browser/application. I have two different concerns. The first is that I frequently end up having to clear my browser cookies, for a variety of reasons. Every time I do, I have to redo the 2FA dance, on every single website that requires 2FA. I suppose I could find a different cookie management strategy, but I think it's good for both privacy and security to treat cookies as semi-ephemeral. Secondly, I’m concerned that I'll either loose or replace my 2FA device and forget about the account until it's too late—again, I’m much more concerned about losing access to my account than someone else getting in. I would almost certainly loose any physical backup codes. I also have a fantasy that I'll give up my smartphone one of these days, or at least not bring it everywhere I go. I’ll probably never do it, but the idea is such that I don't want to depend on an app for access to my account. I do think I’ve successfully made myself less dependent on my smartphone than a lot of people, and I’m proud of that accomplishment.
  - ThePowerOfFuet 5y ago
    Then try TOTP, and back up your seeds.
  - rolandog 5y ago
    Have you thought about multiple 2FA devices? To my knowledge, you can use as 2FA w/Google: 1. A prompt on your phone 2. A hardware security key 3. TOTP token from authenticator 4. one of 10 backup codes And you can also have multiple security keys as well, which is useful if you lose one.
    - Wowfunhappy 5y ago
      A prompt on my phone and an app on my phone come down to the same thing, and I'm not interested in getting a physical hardware security key. The backup codes are one-time use, and there is no way I would keep track of a slip of paper for years without loosing it. I could use my password manager (Bitwarden) as my TOTP generator, and I may eventually do that just to make all of these services shut up. But, wouldn't that leave my account no more secure than it already is today? It would effectively be single-factor authentication, since the password and the generator would be in the same place, protected by the same master password.

prophesi 5y ago

Sweet, I was about to look into whether I'd need to make changes to my OAuth integration. Makes sense that it's fine since the username/password (or however they wish to authenticate) is sent to Google themselves.

folmar 5y ago

There are still non-web applications, so no, that's not a third party. If I save my credentials in Mutt/Pine it's more secure than entering them in the browser - much less attack surface, and not more third party than a browser. There are some benefits to having a token like in oauth, for example simple way to revoke some sessions access, but it's a tradeoff, not black and white.

michaelmrose 5y ago

You aren't necessarily actually sending it to a third party per se though. Less secure access also enables using software running on your own computer to access your email easily. For example offlineimap and imapfilter. In theory it ought to work with OAuth but damned if I can get it to work and any instructions a few years old are useless because something has changed in the interim. It's actually less hassle to migrate off Gmail. Quite frankly there are few Google things that at this point aren't a hassle to work with. Google is poised to ruin adblocking in chrome with manifest v3, search is increasingly polluted by junk, gmail is now a pain to work with outside of a web browser and awful to use in a web browser, the play store is so bad as far as finding non junk non malware that its necessary to use an outside web page like say bing/duck duck go to find apps to install with play store which serves at best as an updater interface, workspace is a pain. Various actually useful services like reader picasa google+ are dead. The only remaining useful end user services are youtube, maps, and android. As someone who used to be excited about Google stuff its kind of disappointing. Gmail user from June 2004-2022 but soon no longer. Thanks for 18 years of good service for the absolutely ridiculously low price of I think $80 to date.

jefftk 5y ago
> Less secure access also enables using software running on your own computer to access your email easily. For example offlineimap and imapfilter. In theory it ought to work with OAuth but damned if I can get it to work and any instructions a few years old are useless because something has changed in the interim. You shouldn't need OAuth; have you tried application-specific passwords (https://support.google.com/accounts/answer/185833 https://support.google.com/accounts/answer/185833)?
- michaelmrose 5y ago
  If this is an effective workaround why is it useful to disable the feature in the first place. It seems like a 16 digit password this is actually much less secure than the current state of affairs. It's probably not much worth exploring because I'm also having to migrate off of legacy google apps for your domain as well.
- 5y ago

dcow 5y ago

I really think Google needs to make a distinction between sending your credentials to a foreign 3rd party service/domain vs a “3rd party” client that runs on your machine. Sending your credentials somewhere else is understandably best avoided. Using a different “3rd party” user agent than the top 3 browsers to access some google services, on the other hand, really isn’t less secure at all and I even think an argument could be made that it’s more secure than a browser in many cases. Local (wouldn't even mind if it was limited to open source) apps should be given unrestricted access to the Gmail OAuth scopes. Until then, I can’t see how this is anything other than a platform control play under the guise of user safety to lock down API access to blessed google clients and services.

jefftk 5y ago
> Local (wouldn't even mind if it was limited to open source) apps How could a rule like that be enforced? > lock down API access to blessed google clients and services. What's wrong with application specific passwords? (Still speaking only for myself)
- dcow 5y ago
  > How could a rule like that be enforced? Considering the review process is currently subjective, then subjectively I guess. If you say in the review that you're an open source app and that you only do native OAuth locally then you get approval. Google already requires a link to your project's homepage maybe additionally you have to provide one to your source code so the reviewers can verify. If you prove to be untrustworthy and in violation at some point in the future then your access gets pulled. Maybe the problem is that google is trying to enforce client behavior in the first place? I thought the point of OAuth was that the user gets to approve or deny access to granularly scoped resources on their account, not google.
- dcow 5y ago
  Re app passwords: aren't you still a "less secure app" then? Really it's the messaging https://support.google.com/accounts/answer/185833?hl=en https://support.google.com/accounts/answer/185833?hl=en: > Tip: App Passwords aren’t recommended and are unnecessary in most cases. To help keep your account secure, use "Sign in with Google" to connect apps to your Google Account. > > An App Password is a 16-digit passcode that gives a less secure app or device permission to access your Google Account. App Passwords can only be used with accounts that have 2-Step Verification turned on. So e.g. I'm trying to build a "more secure" app that uses sign-in with google like it's supposed to and Google says "sorry your use case isn't approved". My recourse is just be a less secure app? Isn't that a little unfair? More-so, according to google's messaging, doesn't that make the user less secure?

yoavm 5y ago

Sometimes you can't use OAuth because your client doesn't support it. If you ever run into that problem you might find my project useful - OAuth Hopper serves as a simple proxy that removes OAuth from services. github.com/bjesus/oauth-hopper/