Hacker News Reader

Comment by jefftk | Hacker News Reader

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) and OAuth are much better.

Disclosure: I work for Google, speaking only for myself

View on HN

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

I do think you're right about 2FA, and there should be an option to use an application specific password without 2FA.

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.

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

Then try TOTP, and back up your seeds.

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.

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.

I’m not sure about Bitwarden, but 1Password requires quite a few pieces of information to log in on a new computer, because it derives the encryption key from both the hash of your password and the “Secret Key”. Effectively, it still IS 2FA, with the “something you have” factor being a device activated with the secret key and your 1Password OTP. If you don’t sign into your password manager on your computer directly this should be fine. But you do, of course, lose the ability to paste passwords.

But regardless of how the vault is protected, your password and your otp generator are both stored there, right? If you have access to one, you have access to the other. So, I don’t understand how requiring both to log in to Google improves security in any meaningful way.

It's often much easier for someone to manage to get a copy of your password for a specific application than to get a copy of your unencrypted vault.

That's more friction than I'm willing to tolerate. If they force me to use 2FA, I'm done with Gmail for good (it's already no longer my primary email).

And I'm not against 2FA in general, I just don't want to use it in this case.

Googles 2fa requires the user to give google his phone number before being able to add a totp authenticatior. That alone is reason for me to never use it for my google account. The popup also doesn't come up if you haven't signed up with google on your phone, obviously. There is nothing stopping them from just allowing anyone to add a normal totp 2fa generator, they just chose to not do that to get more of that sweet, sweet data.

Does Google fall back to SMS if you tell it you lost your totp authenticator? That’s problematic in its own way, but it would explain the phone number requirement.

Not if you remove the phone number afterwards. It just requires the phone number before enabling the normal otp.

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.

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

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.

Oh, so you still support application specific passwords. I couldn't find them when I last looked, or maybe it was because applications just moved to the OAuth2 model and didn't offer the option. I'm pretty sure Thunderbird's calendar extension doesn't.

I didn't ever understand why Google allowed you to enter a password into a random piece of software. In fact I'm still somewhat perplexed by them letting you enter it into a browser, but I guess they could be using the browser DRM module to get some assurance they are dealing with software they can trust.

I guess it's just too hard to make move everything to hardware security tokens. Nonetheless, I don't see an choice in the long term - physical security tokens that don't allow firmware upgrades is where we must end up.

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.

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

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

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:

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

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.

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.

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/

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.

Reply on news.ycombinator.com