Live data from Hacker News

Bruteforcing the phone number of any Google user

brutecat.com

131–140 of 204 posts

Re: Bruteforcing the phone number of any Google user

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

[BuyVM](https://my.frantech.ca/cart.php?gid=37), a popular host for shady operators, gives a /48 even with their cheapest plans ($2/month, though only $7/month is in stock right now)

Re: Bruteforcing the phone number of any Google user

#132

Earlier quoted context omitted.

On the other hand they had no idea if the information was valid or wildly outdated. But better something than nothing I guess. :-)

This is where modern "learning" falls down. You load a page, read its contents, compare with what it is supposed to be, update if outdated, move on. I know I know, that sounds like, egad, work, but that's called a job. Your immediate dismissal of an actual task I've been assigned irks to the point of being given a snarky response.

Sorry if it irks you, that was not my intention.

My point was not that this job doesn't deserve attention (it does!), but that it would deserve attention from the senior personnel, not (just) the interns. I've seen too many times how important tasks, which are difficult to achieve for someone who wasn't there, are given to newcomers with little oversight and guidance. Maybe that's not how it is here, in which case - good for you!

Re: Bruteforcing the phone number of any Google user

#133
post #112

Earlier quoted context omitted.

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

What stuff?

Re: Bruteforcing the phone number of any Google user

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

I'd be rather surprised if IPv6 hasn't done some damage to the idea of IP blocking on the whole. It's possible, even as a residential Internet user, to request a /56 or /48 automatically with DHCPv6 Prefix Delegation. I have a /56 with Comcast. That's potentially up to 65536 /64 blocks, just from a residential user, so if you're going to attempt IP filtering for IPv6, it's got to be a lot smarter than swapping out yo…

How are you getting a /56 from Comcast? I can only request up to a /60 from them, any larger and I get a /60 rather than whatever I requested.

Re: Bruteforcing the phone number of any Google user

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

I'd be rather surprised if IPv6 hasn't done some damage to the idea of IP blocking on the whole. It's possible, even as a residential Internet user, to request a /56 or /48 automatically with DHCPv6 Prefix Delegation. I have a /56 with Comcast. That's potentially up to 65536 /64 blocks, just from a residential user, so if you're going to attempt IP filtering for IPv6, it's got to be a lot smarter than swapping out yo…

It actually makes things a easier for both blocking and allocating (e.g. VPS hoster) side.

Once the "oh no, we can't afford that many unique allocations" excuse is away, algorithms that enforce quotas for every prefix size at the same time (with no excuses for CGNAT weirdness) stop being too ruthless.

You can distribute your addresses as needed, and I can track successful and failing attempts - at whatever distribution scheme you use. E.g. group your "unverified" or "trial" accounts at a larger prefix size, so they get each other blocked - but not your paying customers.

Re: Bruteforcing the phone number of any Google user

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

[BuyVM]( https://my.frantech.ca/cart.php?gid=37 ), a popular host for shady operators, gives a /48 even with their cheapest plans ($2/month, though only $7/month is in stock right now)

A bit more context: BuyVM is a legitimate business, popular with hobbyists, and has features that are hard to get elsewhere (e.g., BGP sessions). They do take a pro-free speech stance but they are a far cry from bulletproof hosting ("shady operators"). An imperfect comparison at a massively bigger scale would be Cloudflare's prominence in certain contexts.

Re: Bruteforcing the phone number of any Google user

#138
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…

Bug bounty program appears to be an efficient spend. For a few thousand dollars they mobilize unpaid people looking for extreme edge cases and then surface these issues. It would’ve cost way more to pay an employee to search for this.

Yeah, $5k seems awfully cheap considering the effort entailed and the potential impact of this big.

Re: Bruteforcing the phone number of any Google user

#139
> 2025-05-15 - Panel awards $1,337 + swag. Rationale: Exploitation likelihood is low. (lol)

Yeah, no, the exploitation likelihood of this is very high. The number of users who might have their phone numbers revealed might be low, but I guarantee you that private investigators, detectives, criminals, etc. would all use this if they needed it and it was there.

Re: Bruteforcing the phone number of any Google user

#140

Earlier quoted context omitted.

What is the point of assigning something to a new hire, if they can't do it without another person watching the whole thing over their shoulder AND they are unlikely to benefit from this knowledge in the future (since it's a legacy page that is supposed to be deleted)?

Anytime a website is created, the information/text to used in the site is provided to the devs. You provide the same data to the QA team to ensure the Dev team did their job. How are we seriously this obtuse? Is it deliberate?

Instead of snark please re-read the entire comment thread from the beginning and you'll realize that the scenario you're imagining is completely different from what is being discussed.
Post reply on HN