Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bruteforcing the phone number of any Google user

brutecat.com

Post reply on HN
Print view View original

121–130 of 204 posts

Re: Bruteforcing the phone number of any Google user

#121

Post by xp84 »

ge96 wrote: post #14
jasonthorsness wrote: post #9

To anyone whose number hasn't already leaked to the B2B SaaS outbound databases: do everything you can to protect your privacy there is still hope for you, the rest of us are already lost

I think it's hard to top Equifax's breach/leak

Indeed, I think if our government weren't absurdly corrupt and incompetent that breach should have triggered two things:

1. Announce a timeline to publish SSNs publicly for all people (forcing function for businesses who might drag their feet)

2. Before #1 comes to pass, issuance of actual credentials to replace SSNs for multiple purposes, credentials that

   A. can be validated in an online process

   B. you can get multiple credentials that all tie back to a secure identity for credit reporting purposes, and you can be notified when new credentials are generated

   C. and (*crucially*) can be invalidated for future use when compromised
3. Regulation of the consumer credit reporting industry to force them to only report future credit report lines where identity was validated according to the new process, not just from "1FA" based on a number the credit industry themselves already leaked for the whole country.

#2 is not easy! It would be a massive project. But it's hard to argue that keeping the absurd "secret 9 digit number" joke going isn't even less viable than taking that project on would be.

Re: Bruteforcing the phone number of any Google user

#122

Post by stackskipton »

growse wrote: post #112
stackskipton wrote: post #98

Earlier quoted context omitted.

Say what? IPv6 was designed that first 64 bits are network, last 64 bit are host. Since /64 is smallest network in IPv6 and because of that most providers hand out /64 when you ask for IPv6 public address because A) Most Rate Limiting uses /64 and B) IPv6 has so many IPs, no one cares. Vultr has at least one /32 I was able to find (2001:19F0::/32) which if you cut that into /64 comes out ~4.2 Billion different networ…

> Since /64 is smallest network in IPv6 A /64 is not the smallest network in IPv6. Nothing stops you having a /112 or a /126 or whatever you like. It is the only network size on which SLAAC works however, so it's a good choice for lan sizes.

I'm talking practical. I know you can reduce networks further BUT there is plenty of stuff that could break.

Re: Bruteforcing the phone number of any Google user

#123

Post by vladvasiliu »

zerof1l wrote: post #62

This article highlights something interesting... it is quite common to get at least one /64 IPv6 block from a hosting provider or ISP. Yet most of the rate-limiting and IP blocking is done for a single IP. Sounds like when dealing with IPv6, an entire block of /64 should be rate-limited or blocked.

Even companies which not only should know better, but are actually paid to handle things like this get it hilariously wrong.

The company I work for is a client of a big-ass CDN you've heard of (not the one whose ceo hangs around these parts). Yet, they somehow think it's fine to notify me of "new connections from an unusual IP" when I connect from the same /64 block of ipv6.

Re: Bruteforcing the phone number of any Google user

#124

Post by bsamuels »

zerof1l wrote: post #62

This article highlights something interesting... it is quite common to get at least one /64 IPv6 block from a hosting provider or ISP. Yet most of the rate-limiting and IP blocking is done for a single IP. Sounds like when dealing with IPv6, an entire block of /64 should be rate-limited or blocked.

IP rate limiting hasn't been a serious misuse prevention tool for 15-20 years

Re: Bruteforcing the phone number of any Google user

#125

Post by xnx »

jeffbee wrote: post #79
xnx wrote: post #68

Earlier quoted context omitted.

> Eventually you will land on a popup that uses the original Gmail look and feel, from 2004. Indeed, I recently ran into a Google page that served up the old (~2013) Catull logo.

I tried to guess what it might be ... I went to check moon.google.com, one of the older apps/jokes that I can recall still running. It seems that they got someone to update moon.google.com with a more recent look and feel, and dozens of moons instead of just the one. And people say Google abandons products.

I'll share the url somewhere if I come across it again.

Re: Bruteforcing the phone number of any Google user

#126

Post by ctkhn »

jeffbee wrote: post #4

It must be a daunting chore to maintain all the legacy pages. The amount of now-years-old stuff that long-standing sites have to maintain, or choose to maintain, is shockingly high, and testing the combination of all that stuff is impossible. If you want an example of how diverse in age these apps are, dig around in the Gmail settings panel. Eventually you will land on a popup that uses the original Gmail look and fe…

There are major things at some large enterprises that are given the same level of support. Friend works on an internal link shortener app that is heavily used at their mega corporation and it gets maybe one ticket every other sprint just for upgrading node versions etc even though its monitoring is down.

Re: Bruteforcing the phone number of any Google user

#127

Post by hayleox »

xnx wrote: post #119
hayleox wrote: post #87

Earlier quoted context omitted.

I was recently editing the Wikipedia page for Google Bookmarks (2005-2021). I wanted to add a logo to the page, but I was having a lot of trouble finding a high-quality copy of the logo anywhere. Eventually I figured out that Google's old URL scheme for product logos was very guessable, and they had never taken it down: https://www.google.com/intl/en-US/images/logos/bookmarks_log... They'll probably never stop servin…

That's good! Cool URLs never die. I thought they would be able to do a more effective search of their codebase to find references to their old logo in their own code.

I'm sure they could, but to what end? It'd be a bunch of work to find them all, and they could never really be sure they didn't miss one. Meanwhile the cost of just serving that old logo forever is basically nothing.

Re: Bruteforcing the phone number of any Google user

#128

Post by demosthanos »

bsamuels wrote: post #124
zerof1l wrote: post #62

This article highlights something interesting... it is quite common to get at least one /64 IPv6 block from a hosting provider or ISP. Yet most of the rate-limiting and IP blocking is done for a single IP. Sounds like when dealing with IPv6, an entire block of /64 should be rate-limited or blocked.

IP rate limiting hasn't been a serious misuse prevention tool for 15-20 years

Can you elaborate? As one tool among many it seems to me to be a perfectly serviceable tool in the toolbox, with a sufficiently high rate limit to account for shared IPs.

Re: Bruteforcing the phone number of any Google user

#129

Post by dooglius »

hayleox wrote: post #83
okanat wrote: post #53

Earlier quoted context omitted.

While your argument seems to make sense on the surface, it fails in deeper inspection. What security implications did Google Reader have? I do understand keeping older APIs and endpoints for authentication and authorization are indeed dangerous. However, if your architecture causes the mere clients of those authorization infra to be exploited, I think the problem isn't keeping the products running. You designed somet…

Google Reader used Google accounts for authentication, so an exploit in Reader could potentially be compromising to your entire Google account. This very article gives an example of that; Looker Studio was used to reveal the name on any account, even though most accounts have likely never used Looker Studio. Google could mitigate this by not having universally shared accounts across all services, but they're not goin…

The counter-argument would be that if you consider the name on an account to be something needing security protections, then Looker Studio code should not have had the ability to access the name on an account.

Re: Bruteforcing the phone number of any Google user

#130

Post by [deleted] »

mystifyingpoi wrote: post #114
shwouchk wrote: post #110

Earlier quoted context omitted.

g has been demanding a valid phone for years, as have most other major providers. if you lose the number you sign up with, you can potentially get locked out of the account. whats your mo?

Not sure how it looks in USA, but in EU you can get a prepaid SIM card for $2 and use it forever for cases like this. You'll probably have to top it up with another $1-2 if used sparingly, but that's the price of such separation.

[deleted]
Post reply on HN