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.
Bruteforcing the phone number of any Google user
131–140 of 204 posts
Re: Bruteforcing the phone number of any Google user
#132Earlier 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.
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
#133Earlier 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.
Re: Bruteforcing the phone number of any Google user
#134This 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…
Re: Bruteforcing the phone number of any Google user
#135This 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…
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
#136This 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
#137These bug bounties pay peanuts. Sad.
Re: Bruteforcing the phone number of any Google user
#138It 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.
Re: Bruteforcing the phone number of any Google user
#139Yeah, 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
#140Earlier 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?