Here's a list of things that are wrong with what Google does:

- If you want to read your email, you have to use app specific password. I'm ok with that.

- You can't generate app specific passwords if you don't have 2FA enabled. That's some artificial limitation made to force you into adding phone number to your account.

- You can't use authenticator app to enable 2FA. I have no idea why SMS which is the least secure way to send information is a primary method and authenticator app which can be set up by scanning QR from the screen without sending any information at all is «secondary» and can only be used after you give your phone number.

- You can use «notification» to confirm it's you, but you can only do that on the phone. I'm currently logged in in my browser, certainly I could confirm any login attempt from that same browser, wouldn't that be a second factor?

- Nowhere in announcements or help pages or in the Google Account interface they tell you that you can't generate app passwords if you don't have 2FA. The button is just missing and you wouldn't even know it should be there unless you search on the internet.

- Nowhere they tell you the only way to enable 2FA is to link your account to your phone number or to your android/iphone device, the options are just not there.

All of this is just bizarre and ugly. I have no idea why other people are not complaining, probably most of them just accepted that and added phone numbers.

Are you sure about that? I don't think this is true. I definitely don't have a phone number linked to my Google Account and I have TOTP enabled as well. They even have the Advanced Protection mode which doesn't allow SMS or the authenticator app.

Really though, you should do the last thing. Buy some security keys and enable Advanced Protection.

Only then you can add other authentication methods (this a hardware key) and remove your phone as an option.

Source: went through this nonsense a couple years ago and then again a couple months ago with a different account.

There is ABSOLUTELY an option to enable 2FA on a Google account now that does not require giving them a phone number. There's a clear "Advanced Options" link that lets you choose a security key, which is what folks should be using anyway.

Other than security key, it's only phone number or adding account to the phone.

I'm sorry I didn't mention that in my post, I wasn't trying to lie, I just can't obtain physical key and I don't think I have to have physical key to read my emails.

If there is a way of doing it, I suspect it's deliberately well hidden. I also suspect what they enforce varies by country.

Besides, you don't need an actual physical key for U2F.

I set up 2FA to use Yubikey hardware keys for a google account, and was then allowed to generated app passwords. No phone number has ever been attached to the account.

I do agree that not allowing app-passwords to be generated without setting up 2FA is coercive and seems hard to justify, and it is plausible that it is being used to push people into attaching their phone numbers to their accounts. If I recall right, the current language for the setup process skews heavily toward phone numbers and does not do a good job of highlighting other (more privacy oriented) alternatives (as may be evidenced at least in the case of OP).

If now it's just 'not recommended' then this is an improvement.

So the rules can vary by region

I'm really glad that I've never used a gmail address for email before, I'd hate to be stuck with using anything run by Google.

Companies using google apps, keep in mind, you pay money for a service but if there's google involved, you're still a product, just avoid it

My personal consumer MSFT/Xbox account also has no mobile number attached.

Most of our people including myself choose to enroll a personal phone rather than carry two devices, and somehow none of these hundreds of people ever provided their mobile numbers to Microsoft. I think you are mis-remembering the setup experience, or your employer chose to enable some non-default options that uses SMS as a backup option to the app.

You always need to add a phone as your first MFA method.

A simple hack though:you can add other methods, then remove phone.

Your account was likely created before phone MFA was mandatory (as the first method).

Sure. That's like when I deleted my DigitalOcean account. They still send me notices about their service. Just because something is deleted for you doesn't mean it's deleted for them.

If you use an Android phone, you most definitely do have a phone number associated with your Google Account. Android sends your IMEI and SIM card info to Google servers.

Agreed

> You can't use authenticator app to enable 2FA. I have no idea why SMS which is the least secure way to send information is a primary method and authenticator app which can be set up by scanning QR from the screen without sending any information at all is «secondary» and can only be used after you give your phone number.

The amount of people getting locked out of their account because they lost the phone with the auth app would be unacceptably large, is my guess. Like people lose their phones all the time. Simjackings are rare.

Carrying that around in a wallet doesn't make you any more vulnerable to physical attackers than carrying your Yubikey on a keyring, and it's much more secure against remote attacks than SMS-2FA (where you can fall victim to SIM swapping, number porting attacks etc).

But he talked about traveling.

IDK about you but I don't travel with a safe in my backpack

That makes the whole "stolen luggage" thing even far riskier. :/

Again, the recovery code is one factor.

It might have something to do with not wanting to have tons of spam accounts out there? Do they have code to keep a closer eye on unverified accounts?

Or preventing broken devices from locking people out, in a "We must protect users from themselves" kind of way?

Google is a mass market company, clearly not a privacy company, anyone who really wants to not be constantly tracked should probably stay away for many more reasons than this.

Some sites (e.g. Scaleway.com) won't accept VOIP numbers: they require numbers from actual mobile networks. That is a pain for me since my main phone# is a VOIP number that forwards to my mobile. I do that so I can change my mobile number and just update the forwarding target, or can forward to a landline if I'm someplace with a lousy mobile signal, etc. All of this sucks.

some (like visible) allow you to sign up without providing any of your own PII

I used to constantly get emails about suspicious logins detected simply from moving around hotspots with my phone trying to log into IMAP. This was until I enabled the app password thing, which generated a password that's both shorter and uses less different characters than my old IMAP password.

None of the service providers who claim to fix the issue are worth their weight in salt. Shape, Akamai, none of them have a grip on the problem because the attackers are constantly evolving. As you can see, even Google is capitulating despite all the fud that people on HN spread about the company being omniscient.

Anyone who thinks this is about advertising/collecting personal data is out of their minds.

The worst part is nobody can talk about it because anything you reveal about your problems can give the attackers a massive edge.

250M login attempts times a few seconds of CPU time is a lot of compute cost to inflict on an attacker who is carrying out the same attack against a bunch of other services at once, and virtually nothing to the few thousands of active users who should only be logging in once every few months each.

And yes, a few extra seconds of logon time is viable, because people are used to the login process taking a few seconds and they don't do it very frequently.

"Credential stuffing" is straight-up an invalid excuse for asking for someone's phone number.

[1] https://en.wikipedia.org/wiki/Hashcash

In a normal attack, there are maybe 2-3 requests per hour that come from each hacker-owned device. The only thing that hashcat would do is drastically increase power consumption at no cost to the attacker, and turn the application into a battery drainer on mobile devices.

So no, Hashcat is not an adequate solution.

False for a very large variety of low-power IoT devices using chips like the ESP32, which are multiple decimal orders of magnitude slower than a modern computer (or high-end smartphone) and will absolutely take far longer to compute a Hashcash challenge than one of those devices. Your smart light bulb is absolutely not hosting a Qualcomm Snapdragon 450 to change its colors.

Additionally, adding this compute+power load causes the presence of malware to become far more visible on these devices, which increases risk of discovery, which is a significant upside.

Finally, because there's now a significant computational cost to performing a login attempt, the value of individual devices are further decreased to the attacker, which reduces their likelihood of compromising these devices, and for using them for these kinds of attacks against services that use this measure.

So, yes, Hashcash is absolutely an adequate solution, and yes, there is absolutely a cost to the attacker.

Hashcat was proposed over 20 years ago. You really think out of all the tens of thousands of security engineers working on this problem, nobody has ever considered it? Get a grip.

I hate how this website incentivizes people to try to make posts that sound smart instead of posting stuff they're actually knowledgeable about.

Above you say they are IoT devices. I don't mean 'gotcha', but to learn: What does the population of botnet devices consist of?

Realistically though as long as it can send a request I think attackers would prefer lower power devices someone's computer may be able to send many more r/s but much harder to gain control of versus the $30 iot device.

Some of your attackers are going to run your proof-of-work algorithm on a 3090 Ti GPU and put loads of work into optimising their setup.

Some of your legitimate users are going to run it on a Raspberry Pi 1 with an ancient browser that only runs wasm through a javascript polyfill.

Tough to make up for a 1000x performance difference.

Those legitimate users logging in on a Raspberry Pi 1 are going to be in the vast minority (probably about 0.001%, if not less, as evidenced by the relative marketshares of Windows vs Linux, and how rare Raspberry Pi's are for desktop use relative to normal x86 machines) of users of your service - it's OK for them to have 20s-30s logon times in exchange for (1) not requiring PII from users and (2) less credential stuffing.

Certainly, Raspberry Pi users are more rare than Internet Explorer users, which many developers simply refuse to support at all.

In particular, I am ok with having 30s logon times for services for my desktop computers (assuming that I only have to log on once every few months and not every few minutes like my brain-dead bank requires), so it's more than reasonable to expect those with an extremely niche and underpowered setup to have to wait that long for a very infrequent login process - again, for the sake of security and privacy.

Also there is something to be said for generating the password yourself and sending it in clear to your users by email. The reality is that if the attacker has access to your client’s emails, it’s game over anyway because of password recovery. And this way you enforce that your clients will not reuse a password, and will have a strong non brute forceable password. And if you get hacked, at least you didn’t leak that precious password your users reused everywhere else. The only issue I can think of is that’s because smtp is the most neglected protocol of the internet, there is no way to ensure the email will be encrypted in transit.

Blocking individual IP addresses has never been a valid mitigation against professional attackers. Attackers will just pivot to renting a different botnet from different geographies/ip ranges.

If your service has any level of scale, there can be double digit percentages of users who are sharing an IP address with a hacked device. Blocking attacker IP addresses will block users of your service.

Use rate limiting instead.

Most technology rewards people who own fast CPUs or are using stolen CPU time, so this statement doesn't mean much.

What actually matters is "does this significantly negatively impact those with slower processors" (no) and "is it still effective at punishing attackers" (yes).

Impact: I'll set my Hashcash challenge so that it takes about 8 seconds on a 10-year-old middle-of-the-line Intel processor. There, login time is about doubled for people running that extremely old hardware, and that's the worst case - and this is entirely acceptable given that most people do not log in to their accounts very often - they do so once and then stay logged in for weeks or months.

Effectiveness: Even for attackers using stolen CPU time - Hashcash is still effective. If you have malware on a low-power device, that device is going to be far slower at login attempts. If you have a user-facing device, they're much more likely to notice their computer being slow, and do something that might lead to discovery. If you've stolen compute on some cloud, then the IT folks are more likely to notice, and so on.

Rate limiting is good, but is complementary to proof-of-work - if you have a large pool of IPs/devices to log in from, for instance, rate limiting isn't very effective.

Sorry, but that trust has been burned and I don't see a path to recovery. Support hardware tokens or get off my lawn.

https://www.eff.org/deeplinks/2019/10/twitter-uninentionally... https://techcrunch.com/2018/09/27/yes-facebook-is-using-your...

They couldn't care less about the habits of a nerd on archlinux with ublock, noscript, firefork a vpn, hardware tokens and 2FA everywhere with recovery code split in 7 different location.

That's clearly malice. Like, there's no good reason that Google would require you to hand over a phone number.

Let me give you a reasonable non-malicious reason:

Googler A: "We have this new attack. People are creating accounts from compromised IPs, and then creating app passwords to send huge amounts of gmail spam through SMTP directly, thus avoiding our browser-based spam mechanisms"

Googler B: "Can we ban them?"

A: "We can't ban them because we have no info on them, just sign-up IP, and the botnet has practically unlimited IPs"

B: "What about forcing them to have a phone number so we can do anti-spam on that, and perma-ban compromised phone numbers from making new accounts?"

A: "Good idea, that'll stop such a huge quantity of phishing emails and spam. That'll be good for the internet as a whole"

----

See, a non-malicious explanation.

You do know it isnt mandatory to be a customer.

I ran into a similar situation (small, growing startup dealing with credential stuffing attacks). We have since implemented a few different solutions, but one of the most successful was rejecting reused passwords at signup using this service [0].

Some other effective solutions include captchas, emailing a verification code, etc. Aggressive rate limiting was not at all successful, as the botnets seem to have endless piles of residential ip addresses to send requests from.

[0] https://haveibeenpwned.com/Passwords

The world desperately needs to move away from username + passwords. Google might seem really pushy right now, but it's simply a trailblazer. My prediction: in a few years every company that handles valuable personal information will behave like what Google is doing today.

the rate-limit and blockage time for attempts should increase ban time/lockout-timer on an exponential time scale the more that a single browser/useragent/browser fingerprint/IP makes incorrect attempts.

yes obviously there are people out there with fully automated systems who will try massive lists of commonly used plaintext passwords for authentication if you don't throttle/rate-limit it.

and those people use single browser/single useragent/single browser fingerprint/single IP

the people competent enough to send millions of requests are usually also competent to send hard to detect requests

there are dozens of (free)tools/services offering those capabilities for LEGITIMATE purposes(like scraping)

there is an even bigger underworld market for paid tools for illegitimate purposes

even if you see something like a single /32 address that is probably the public facing endpoint of a mobile phone carrier's cgnat and has MANY users behind it, trying different password attempts, you can still rate limit the number of attempts per unique username.

the actual amount of legit requests that a human who has forgot their password makes is 99.9% of the time under ten requests per account before they give up.

And ok, let's assume it came from the same block of ips(which rarely happens) what do you do when those IP blocks are from IDK, Verizon or AT&T in the middle of New York?You block half the city?

+if the attacker is trying it on all accounts, what are you gonna do? rate limit all accounts? and now anytime a user forgot his password he have to contact support because he can't even do it himself so your support is overwhelmed by 1000s of request every day?

For the end user it is absolutely about collecting additional personal data. My concerns as a user are not the concerns of Alphabet, the company, period.

Think of it like using social security numbers to authenticate yourself to the bank. Yes, it's terrible, but it's kind of the only thing that works when done on a massive scale. Yes, you can do better at managing your 2FA credentials, but most users cannot - they struggle even having strong passwords. Phone numbers bridge that security-usability gap. To be clear, this isn't an endorsement of the system (I think the user should be allowed to choose), but rather trying to make sense from an engineering perspective.

The only valid reasons for the latter are (1) to collect your PII and/or (2) because they think that they know better than you and they're going to force you to do a thing because they think it's in your best interests - in other words, a tyrant ruling over a techno-feudalistic society.

If Google was really concerned only for the safety of their users, and not trying to obtain PII for their personal use, they would build an opt-out button, something that would allow users to print out a one-time-use password/encryption key, or register an alternate email address, in lieu of providing a phone number. They don't.

Your explanation doesn't hold water.

It adds an external cost to creating an account. I imagine this is incredibly valuable in fighting spam across all of their services. No coincidence, the phone number requirement is the only reason I don't have several disposable twitter, Facebook, and Google accounts.

It's an email app. There are many other options.

https://about.google/products/

Calling this feudalism is a bit much.

(I agree that the language he used was a bit much, but I think he was using exaggeration as a legitimate literary device to make his point, not in an attempt to actually mischaracterize that scenario.)

He think it’s the first possibility — that Google is doing it for reasons other than the users’ best interests (i.e. “nefarious purposes”) — which is even worse.

How so? The most realiable one is email, as it doesn't need to be tied to any third party so it can exist a lifetime.

I've had the same email since the mid 90s. I've had probably a dozen or more phone numbers in that timeframe. A handful of which are still tied to various company accounts even though I've long since haven't had any acces to those phone numbers.

Welcome to the club. The fastest way to convince me *not* to use a product is to attach a "Google" label to it. Nothing Google has to offer justifies the drawbacks.

NOTE: I do use an Android phone --- but only after it has been thoroughly de-Googled --- starting from a stripped down, bare metal device that won't even power up.

You're going to have to explain to me. Particularly the "starting from a stripped down, bare metal device that won't even power up. Because this sounds excessive and a bit over the top.

No idea what this is and searching yields nail polish as the result.

A standard Android phone sends your IMEI and SIM card info to Google servers on boot up before you even have a chance to login.

I haven't found a service that functions as well as Google Photos. She takes pics and I take pics, and we have a shared account that backs it all up without any messing about. I have done precisely ZERO tech support for my wife since buying this service and phones and I will probably never leave.

I myself tried to power off the device. Holding the lock button actually didn't show a power off menu, it opened Google assistant. As far as I can tell the only way to turn off the phone was to say "Turn off" to the assistant.

Any of the personal cloud things - Nexcloud, Owncloud, Seafile, Syncthing and others - can be used to sync files - and with that photos and videos - from mobile devices to some server somewhere. This can be the server-under-the-stairs, your NAS at home, a wall-wart with a Raspberry Pi and a drive taped together, a VPS or a commercial entity offering these as SaaS. You can keep using your phones with or without Google, that is up to you. If you run the stuff yourself you'll need to install and configure the parts which make it work, if you use a commercial instance you just have to install the relevant app and tell it to sync your data. You can do this in parallel to using Google Photos, just to make sure you have a backup in case Google wants just that one extra piece of personal data to allow you to access your photos which makes you give up on them. Just one more piece... and one more please...

When I set it all up, I think the fork had much better behaviour around folder permissions for non-root users, I'm not sure if that's true any more.

I wish HN would auto-remove these BS comments about BS comments. They're so tiring and boring...

Google hates open protocols. Don't let their claims of OAuth being open fool you. They don't use OAuth, they use OAuth 2 which is the mega-corp version shoved down the IETF's throat where every single corporate implementation is different and not-interchangable. You need a different OAuth2 plugin for every mega-corp.

I have thoughts of running my own mail server, but a lot of sites just won't let you create an account if you don't provide «trusted» email, and by «trusted» most of the time they mean gmail.

I got myself a domain and trying to set up my mail server, but my VPS hosting is blocking outbound port 25. So I can receive emails, but can't send anything. ispmail guide has no workarounds for that…

We have to be the changes we want to see in the world. Maybe don't use the domain/mailserver for life or death services the first few years and just see how it goes.

While email may be open it was designed in a pre-spam era and we've been fighting the oversights ever since.

Screw you, Google, you're not getting my phone number.

I asked one of my friends with faster internet to do that for me but google blocked an attempt to login with correct username and password.

Afterwards, yes, you have the TOTP secret available for use in any tool you want - but I am repeating myself.

From google's perspective, they're looking at a change which reduces phishing and scams by some small percent, and impacts a minuscule fraction of their users.

Abuse, scams, phishing, and forgotten passwords are all significant problems which phone numbers help with. I'd be willing to bet these changes end up having an on net positive impact for google's users.

How many phishers do you think will be stopped by removing an insecure login flow? How many people do you think want to use insecure apps, but don't have a phone number and refuse to login to their google account on their phone?

I actually don't know. Do you have any numbers?

"OAuth for Gmail is supported via the quick setup wizard. The Android account manager will be used to fetch and refresh OAuth tokens for selected on-device accounts. OAuth for non on-device accounts is not supported because Google requires a yearly security audit ($15,000 to $75,000) for this. You can read more about this here [2]."

1. https://github.com/M66B/FairEmail/blob/master/FAQ.md#user-co... 2. https://www.theregister.com/2019/02/11/google_gmail_develope...

So it maybe works, or maybe not, because they're not paying Google for the security audit.

the SS7/PSTN is horribly broken.

SMS based "2FA" is not actual 2FA

Working in the telecom industry I've seen the pressures that first tier phone service reps are under and how they can be socially engineered, if someone is in possession of enough pieces of a person's identity already, to issue a new SIM or port out a number.

Of course, the real solution is to remove the leverage Google has on you so that a ban is no longer a problem.

And I hope they will never ever again ask me to confirm anything using that number.

Lookup APIs are available to identify line type and most will specifically reject voip numbers. The more obstinate providers I have encountered (some banks for example) will actually have a real human place a call to any number provided at sign up and reject it if they can't verbally talk to you.

For example, https://cheapglobalsms.com/

I went a slightly different route --- an old spare phone with Ultra Mobile PayGo prepaid SIM. For $3 per month you get 100 minutes of voice, 100 texts and 100 MB data per month.

The reason for this is that some security providers throw a little kink in the works by actually making a call to verify your number on sign-up.

Or, you know, stop fucking using google.

https://news.ycombinator.com/item?id=29710908

I have an important Gmail account where I recently had to change the password (because the only password set several years ago didn’t work). Since it was important, I didn’t want to risk the account becoming inaccessible and hence provided my phone number as the recovery number. After changing the password through a browser, the iOS Mail app complained that the password for this account is invalid and that I should enter it. So I go there and flow through the Google login pages (since this is setup as a Google account), and then it repeatedly tells me that it’s incorrect and that I should recover my account. Visiting the recover account page tells me that it cannot help me at this moment!

I’m furious at how stupid Gmail (and the people in Google writing this application) can be. I haven’t accessed that account over the last few days and am hoping I can get back in after the Google bots have cooled down. I have no idea what I can do if that account becomes permanently inaccessible because some “machine learning” algorithm messed things up. :(

I’ve decided to close my Gmail accounts (these were old ones) if I can manage to download the data from those.

This is a prime example of using dark patterns to achieve a short term goal at the cost of creating a world none of us want.

We must all remain vigilant of this trap both as creators and as users.

I applaud you for calling it out. I wish there was something more we could do about it.

The real head scratcher for me here though is that you are fine with Google hosting all of your emails and whatnot but knowing the phone number is a huge problem? If you do not trust Google with your phone number it seems like going with another email service would probably already be a good decision.....

Get a Fastmail account, I got one after I got tired of google breaking my IMAP settings every other week. They're cheap, they have most everything you'd need from an email provider, and they don't require a special app like proton.

I share your sentiment, but I opted for Fastmail because the effort wasn't worth the savings. YMMV, obviously.

The big email providers have basically built a walled garden around email by blocking anyone outside the garden as spam. They have no incentive to open the system to people who run their own email.

on a serious note, it's annoying how fundamentalists eventually keep getting shit right because of idiots in power fulfilling their prophecies (daniel sloss had a nice comedy skit on this)

I suppose that on a time scale of thousands of years, a lot of analytical methods break down (and certainly it would be hard to start any new experiments which take that long to complete), but I think that epistemological bonus points should go to anyone whose interpretation of a prophecy guessed the correct ~50 year period for its fulfilment roughly 1800 years in advance.

https://en.wikipedia.org/wiki/Millennialism#cite_ref-18

One point is that app passwords can be a security issue in itself. If you have one the security page on Google alerts you with a big flashy yellow exclamation point and recommend you you to remove it. I did it, broke my email and took a few days to connect the dots, recreate a new app password and setup email again.

I think the problem they have is that mail clients don't do oAuth. So you always have that security weak link if you need IMAP/pop access.

If your phone gets taken by the police (or stolen), with an authenticator app or sms they can get into your account easily but you're locked out.

A hardware key is the way to go but even then there's no guarantee the police wouldn't take that as well, and most people think having an app on their phone is enough.

And 'email alerts' are even worse, if someone has taken your computer and has complete access to your accounts, an email saying "is this you?" is just gonna make them laugh.

So every account I setup, I have to temporarily provide my phone number to enable 2FA, then setup authy, and then delete my phone number. Obviously Google now knows who the real user is, but I haven't been creating additional accounts to be secret. That doesn't excuse the system, but it's not more than a small hassle for me.

Yes, I do have session in my browser and I would use it as a second factor to manually approve every login to my account from my browser if I had option to do that, but Google doesn't allow that. You can only confirm logins from android or apple device.

Not true in multiple ways.

"Less secure apps" are ones that don't support OAuth. There are plenty of third party email apps that are not considered "less secure apps". E.g Thunderbird or Outlook, or iOS Mail work perfectly fine, as many others.

You can use u2f keys as second factors and don't need to add your phone number as a second factor nor as a recovery phone, as my Google account.

I also get a call, every day, precisely at 9:04am, from random numbers matching the first 6 digits of my phone number.

Protecting my phone number is a dead effort on my end.

What if someone secretly have your password and enable 2FA? The addition of the 2nd factor of auth is a big deal and the process should be as secure as possible.

One day the CEO gets SIM swapped over night...until that day nothing will change.

What HN shows is that a non-trivial amount of peoples entire life is focused on exploiting others inadequacies and this exploitation is portrayed as "normal" by those who profit and abormal by those who now see how invasive ad companies become.

Letting your child sit through an ad is akin to child abuse in my head. Like taking them to a church.

  "You laugh because I'm different.
   I laugh because you're *normal."

After all, this is what advertising (i.e. Google) is all about --- coercing people to act a certain way and buy certain things in order to fit into a particular social stereotype.

Which is worse --- being socially stunted or socially vulnerable?