Bruteforcing the phone number of any Google user

Re:Bruteforcing the phone number of any Google user by stackskipton on Monday June 09, 2025 @02:33PM (#44227635)

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

[ Parent | on HN ]

Re:Bruteforcing the phone number of any Google user by growse on Monday June 09, 2025 @04:10PM (#44228881)

What stuff?

[ Parent | on HN ]

Re:Bruteforcing the phone number of any Google user by stackskipton on Monday June 09, 2025 @06:25PM (#44230215)

Crappy network devices may not handle it properly, SLAAC obviously, I'm sure there are IPv6 tools that expect /64 for host, almost all blacklist setups for IPv6 assume /64.

This RFC has things that may not work properly not to use /64. https://datatracker.ietf.org/doc/html/rfc7421#section-4.2

[ Parent | on HN ]

Re:Bruteforcing the phone number of any Google user by withinboredom on Monday June 09, 2025 @07:12PM (#44230638)

The RFC only mentions issues with a shorter prefix, not a longer one. There should be no issues whatsoever with longer prefixes.

[ Parent | on HN ]

Re:Bruteforcing the phone number of any Google user by johncolanduoni on Tuesday June 10, 2025 @04:09AM (#44233986)

GCP for example hands out /96s to each VM, so this isn’t a theoretical or niche usecase.

[ Parent | on HN ]

Re:Bruteforcing the phone number of any Google user by jsnell on Tuesday June 10, 2025 @04:16AM (#44234029)

Yes, for GCP all the VMs with a /96 in the same /64 will be closely related: in the same project, same VPC network, same cloud region. So from the point of abuse logic it's appropriate to treat the whole /64 as a single unit. (That was the starting point of the thread, even though I realize that due to thread drift that's probably not what your comment was about.)

[ Parent | on HN ]