[HN Gopher] Bruteforcing the phone number of any Google user
___________________________________________________________________
Bruteforcing the phone number of any Google user
Author : brutecat
Score : 415 points
Date : 2025-06-09 14:06 UTC (8 hours ago)
(HTM) web link (brutecat.com)
(TXT) w3m dump (brutecat.com)
| msdrigg wrote:
| [flagged]
| jsnell wrote:
| Logging in at all requires JS, so there's very little value to
| a no-JS username recovery flow.
| jeffbee wrote:
| 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 feel, from 2004.
| belter wrote:
| > It must be a daunting chore to maintain all the legacy pages.
|
| Clearly $350 billion revenue in 2024 is not enough...
| staticshock wrote:
| In addition to having the money, Google also needs the
| incentive to _spend_ that money on such projects. If the
| perceived return on capital is low (or negative!), the
| incentive is simply not there.
| reaperducer wrote:
| _In addition to having the money, Google also needs the
| incentive to spend that money on such projects. If the
| perceived return on capital is low (or negative!), the
| incentive is simply not there._
|
| Perhaps Google should Google the concepts of "customer
| service," "standing behind your product," and "brand
| reputation."
| fsflover wrote:
| Why? Nobody is abandoning their services.
| IAmBroom wrote:
| "Sure, Google retrieved the 10,285 results from my
| obscure query in a few milliseconds, but did you see how
| they stored their 12-year-old company icon image?
| Phhht.... I'm going with Bing!"
| xp84 wrote:
| > Google the concepts of "customer service," "standing
| behind your product," and "brand reputation."
|
| They're probably satisfied with their reputation with
| their customers, who are advertisers. The corporate IT
| folks who buy their G Suite products are also their
| customers, but overall the majority of the users of
| Google's software are not their customers, and Google
| cares about them the same way I care about how the
| gasoline in my car feels.
| Magmalgebra wrote:
| Something that can be hard to appreciate if you haven't
| managed this sort of project is that it can be surprisingly
| hard to throw money at the problem.
|
| If you try to hire at your regular "bar" for skill for boring
| work like this - people will often quit. This is one of the
| reasons many company's integrations are lacking despite it
| being a strategic interest - integration work is miserable
| and doesn't help your career.
|
| Hiring below the skillbar at the same pay, is dangerous and
| often doesn't actually work out - if it was that easy someone
| more skilled probably would have fixed this a while ago.
|
| So you try to pay more for the miserable work - but hold on,
| now you have to pay out of band salaries, and legal tells you
| that opens you to massive liabilities.
|
| Ok - maybe you can just level them differently? No, HR will
| tell you that will mess with all your internal level
| processes - which are key to running the company. They're
| going to add a lot of additional overhead tracking these
| "fake" leveling bands and dealing with the consequences.
|
| None of this means the problem is literally unsolvable, but
| it now requires a huge amount of time and effort from people
| near the top of the company who everyone would much rather
| spend their time on making the company better.
|
| All of this to say - sure you could solve this problem, but
| it's actually much more complex than adding some line items
| to a budget.
|
| Source: have watched many big companies try and fail for
| years to staff unsexy work like this.
| tough wrote:
| isnt exactly this why most of it ends up outsorced to
| consultants or third parties generally?
| AndrewDucker wrote:
| You can give people time to go fix things that bug them.
| Two systems that you use don't work together and it bothers
| you? Have a day a week to fix it.
| xp84 wrote:
| > pay out of band salaries, and legal tells you that opens
| you to massive liabilities
|
| can you elaborate on this?
| mystifyingpoi wrote:
| In my country, there is already a (little known and not
| really enforced) law, that says, that for similar work
| there has to be a similar pay (simplifying massively).
| There is possibly a bunch of workarounds for this (as
| usual), but a good HR will not like the idea of hiring
| another SWE, with the same title as other SWEs, but with
| 2x pay.
| 0xbadcafebee wrote:
| Google's main search page is the slowest page & UI I have
| found on the internet today (not accounting for bandwidth
| limits). Even on modern devices it lags at text entry and
| even rearranges characters in the text box so you have to
| wait 10+ seconds for it to finish loading or it will go
| haywire. The shopping and other pages are actually worse. So
| it appears you're right, $350B isn't enough money to maintain
| a web page in 2025.
| jeffbee wrote:
| There is something wrong with your computer.
| xp84 wrote:
| don't forget how long the google.com redirect takes now if
| you dare to click a link on the SERP instead of just
| consuming their "AI Slop Overview" directly.
| fer wrote:
| > It must be a daunting chore to maintain all the legacy pages
|
| I always wonder who's the one maintaining the "poke" feature in
| Facebook.
| bix6 wrote:
| I thought it was gone but I'm reading it was just hidden but
| re-added to the UI in 2024. That was always my favorite
| feature haha.
| paxys wrote:
| Which is exactly why companies are aggressive about deprecating
| old products and services. "But why can't they just leave them
| running and not touch it?" Because every such service
| eventually becomes a security hole. The only secure code is no
| code.
| okanat wrote:
| 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
| something inherently insecure.
| paxys wrote:
| If "what security implications does _xyz_ have" was easy to
| answer then there would never be another hack or data
| breach. The simple answer is that we don't know. And it is
| very expensive to find out.
| okanat wrote:
| I'm indicating that "it isn't easy to answer" is the root
| of problem there.
|
| It means that the engineering teams were incompetent in
| designing a system with a "narrow waist" security
| infrastructure. Then the solution isn't deprecating xyz
| but fixing the security infrastructure. Otherwise the
| same issues will surface again and again in the newer
| products.
| DSMan195276 wrote:
| > You designed something inherently insecure.
|
| That describes most/all software older than a decade with
| no updates applied. How many libraries was Google Reader
| using that now have known vulns? I'm guessing it's more
| than zero.
|
| This is the same logic as "just don't write bugs", if it
| was that easy everybody would already be doing it.
| olalonde wrote:
| Brilliant. Just write secure code. I wonder why no one
| thought of that before...
| oxguy3 wrote:
| 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 going to do
| that because most users would find that inconvenient.
| dooglius wrote:
| 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.
| okanat wrote:
| Since you're the person that didn't answered with "hah
| you say: don't code bugs", I'll take some time to answer
| you.
|
| > 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.
|
| Guess what else uses Google Accounts? Everything that
| Google needs authentication for. When designing software,
| so much effort is put into its design, possible user
| stories and architecture. We put so much effort into unit
| tests, integration tests, regression tests
| whatnot.Security is no different. When designing
| services, considering the data flow is critical for
| security. An engineering organization should take into
| account of data that needs authentication. Those should
| be separate isolated services.
|
| They can crate security islands for critical parts. Why
| Looker needs to get the full name from an e-mail that
| this person hasn't initiated a two-way contact? Or even,
| why it can in the first place? There is a service that
| does this resolution (Contacts?). Google failed to
| consider that limiting this kind of queries when creating
| this service. It has nothing to do with the functionality
| of Looker Studio. Now anything touches this service has
| problems. The old and the new products. You'll not be
| able to resolve these problems by deprecating Looker
| Studio nor deprecating Reader solved these issues.
|
| > Google could mitigate this by not having universally
| shared accounts across all services, but they're not
| going to do that because most users would find that
| inconvenient.
|
| It is not the sharing of the authentication provider but
| the authorization of the kinds of queries is the problem
| here. It is not the problem with the age of the service
| Looker provides either. Yes you may be able to extract
| some data if the pod running Looker Studio got
| compromised, maybe even PII data. The dependencies can
| get old or can have critical bugs. However, they
| shouldn't be able to be exploited to extract large swaths
| of data due to layering and consideration of security
| architecture. That's why creating those security narrow-
| waist points are so important. They need to be given the
| same care of the correctness of the software and other UX
| goals.
|
| Even a smaller company needs to consider these
| architectural details when designing integrated services.
| With GDPR, you should be able to delete every piece of
| PII. It gently forces you to do the right thing already.
| It is totally unacceptable that bigger companies like
| Google skipping this.
| delroth wrote:
| Google Reader was the last major user of the old social
| sharing stack at Google designed for Buzz, a product mostly
| remembered to these days for United States v. Google and
| the 2011 FTC consent decree. When people redesigned
| Google's social stack for G+ (e.g. all the infrastructure
| like Zanzibar underlying Circles, which to this day is
| close to state of the art!) the choice was between
| migrating Reader to the new tech - which nobody could
| justify the cost of - or keeping the old tech around for
| Reader when that tech was known to have had serious privacy
| issues leading to a major lawsuit.
| xivzgrev wrote:
| 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.
| mmsc wrote:
| Depends on the company. Also It can be a good way to say to
| management, "look, this old deprecated shit needs to be
| replaced because it's insecure; maintenance is a security
| issue"
| rkagerer wrote:
| Yeah, $5k seems awfully cheap considering the effort entailed
| and the potential impact of this big.
| reaperducer wrote:
| _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._
|
| One company I worked for used interns and new hires for that.
| One of the early tasks assigned to the intern pool was to comb
| the web sites for outdated information, or things that no
| longer conformed to the current brand book. The list then went
| somewhere else so the pages could be updated or deleted.
|
| The major benefit of this was giving the new people an overview
| of what we do, why we do it, and a slice of the history of the
| products.
| bornfreddy wrote:
| On the other hand they had no idea if the information was
| valid or wildly outdated. But better something than nothing I
| guess. :-)
| dylan604 wrote:
| 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.
| valicord wrote:
| How does a new hire know "what it is supposed to be"?
| snmx999 wrote:
| The information is transferred through a method called
| "communication" by another human.
| dylan604 wrote:
| It is shocking how many people fail at this. If you were
| the employee and did not have enough information to
| perform the task, speak up. You are not going to get in
| trouble or whatever other type of situation one might
| imagine for not asking.
| valicord wrote:
| 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)?
| dylan604 wrote:
| 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?
| valicord wrote:
| 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.
| jeffbee wrote:
| I often assign things to new hires because I expect them
| to approach the question without the biases of long-time
| team members who have learned to overlook and normalize
| some bullshit. Either the new person is wrong, and I
| explain why, and they learned something, or they're right
| and the existing stuff can't be defended or justified,
| and I learned something.
| pests wrote:
| OP originally pitched the website clean up work providing
| a way to learn about the company, its products, history,
| etc.
|
| If something is obvious, sure, but how is the new intern
| even going to know when to ask?
| bornfreddy wrote:
| 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!
| xnx wrote:
| > 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.
| jeffbee wrote:
| 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.
| xnx wrote:
| I'll share the url somewhere if I come across it again.
| oxguy3 wrote:
| 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 serving those old URLs because
| who KNOWS where they might still be in use. One of surely a
| million examples of weird little legacy things Google is
| stuck with.
| xnx wrote:
| 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.
| oxguy3 wrote:
| 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.
| ctkhn wrote:
| 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.
| Brybry wrote:
| > This time can also be significantly reduced through phone
| number hints from password reset flows in other services such as
| PayPal, which provide several more digits (ex. +14*****1779)
|
| I've never thought about this but it's extra scary. If you have
| the same phone number and email address with enough services and
| they all mask in a different order for reset hints...
| dkdcio wrote:
| what's the risk? your email being made public? your phone
| number?
| rvnx wrote:
| Get personal info, then call carrier for a SIM swap, access
| crypto from there. Bonus: no KYC, since it's the other
| person's identity + you can login from 4G internet, so a
| trusted IP range.
| shruggedatlas wrote:
| What can be done to protect oneself from a SIM swap attack?
| sgjohnson wrote:
| Absolutely nothing whatsoever.
|
| If SIM Swap doesn't work, you can always attack SS7.
| There's also nothing you can do about that.
|
| So stop using your phone number as an authentication
| factor. It's trivial to pwn for any actor determined-
| enough.
| qingcharles wrote:
| Where can I get this though?
|
| I haven't been able to get into my main Google account for
| years because they enabled 2FA without warning and it had a
| phone number I no longer have. I have the username and
| password and I get all the emails because I also have the
| recovery email address. I just need to get the recovery
| code by SMS.
| c22 wrote:
| Even scarier, whoever has access to admin those services can
| just look up the unmasked data! Better to use unique numbers
| and addresses per service.
| rvnx wrote:
| There are now Telegram bots to find such information. The fact
| that this bruteforce was revealed probably annoyed many users
| (like the infamous "EoG" bot).
| lesuorac wrote:
| There were a few stories in the past about people social
| engineering their way past support by asking one companies
| support for the last 4 of a card and then using that last 4 for
| a different company.
| anonymars wrote:
| Here's the one I'm thinking of (time flies, doesn't it?)
|
| https://www.wired.com/2012/08/apple-amazon-mat-honan-
| hacking...
|
| > Those security lapses are my fault, and I deeply, deeply
| regret them.
|
| > But what happened to me exposes vital security flaws in
| several customer service systems, most notably Apple's and
| Amazon's. Apple tech support gave the hackers access to my
| iCloud account. Amazon tech support gave them the ability to
| see a piece of information - a partial credit card number -
| that Apple used to release information. In short, the very
| four digits that Amazon considers unimportant enough to
| display in the clear on the web are precisely the same ones
| that Apple considers secure enough to perform identity
| verification. The disconnect exposes flaws in data management
| policies endemic to the entire technology industry, and
| points to a looming nightmare as we enter the era of cloud
| computing and connected devices.
| paxys wrote:
| If it makes you feel better (it probably won't)
| hundreds/thousands of services have collected your phone number
| over the years (for 2FA or any other reason), with or without
| consent, and a large chunk of them have had data breaches. So
| your name-email-phone number combo is 100% already available in
| public data dumps.
| nicce wrote:
| If you have used Twitter or Facebook long enough while
| keeping the account, public your information is.
| westmeal wrote:
| Thanks yoda
| paxys wrote:
| Or Yahoo, AT&T, T-Mobile, Equifax, Capital One, Chase,
| eBay, Home Depot, Marriott, most health networks...
| permo-w wrote:
| not so long ago practically everyone's name and phone number
| was available publicly for free in any phone box
| Rychard wrote:
| Not to mention that these "phone books" also included
| everyone's address, and married couples were usually listed
| together.
| ghaff wrote:
| Yeah, you could get an unlisted number but you were
| charged for it and almost no one did because it was also
| how people you wanted to get in touch with you found you
| a lot of the time. Not that data breaches aren't bad but
| a lot of the breached info has been pretty routinely
| available for a very long time. (And, as you say, cell
| phone numbers are probably less routinely available than
| landlines were.)
|
| I don't go out of my way to publish my cell or address
| but a _lot_ of people have them.
| wat10000 wrote:
| You could pretty easily opt out of that, at least in many
| places, although you might need to pay a small fee.
| dylan604 wrote:
| people always trot this out, but it was very possible to
| have your information unlisted so it was not printed in the
| book. you could also use a different name. an old coworker
| selected to have his name listed as David King so that when
| found in the book it would show up as King David.
|
| having an unlisted number wasn't uncommon. for privacy
| minded people, it was a simple phone call to make it
| unlisted, and most just did it at time of getting the
| number.
| 946789987649 wrote:
| When I was at university, I went to a talk from a security
| researcher who found this was the case with credit cards.
| 0x_rs wrote:
| There's services that do this automatically for a price, and
| they've been around for a while, for e-mail, phone numbers, and
| much more. Any bits (literally, _bits_ ) of information given
| without authorization (or plausible belief it's the intended
| user on the other side) will be efficiently put together from a
| variety of sources, as there's no shortage of incentive, and
| many all over the world prodding services used by billions of
| people worldwide. And then eventually leaked..
| ghaff wrote:
| There used to be deep web services that provided a lot of
| this stuff for free back in the early 2000s or so. I think
| everything like that is behind at least some level of paywall
| now but it's not hard to get a fairly complete dossier on
| someone given a bit of background information and a pretty
| small expenditure.
| jasonthorsness wrote:
| 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
| ge96 wrote:
| I think it's hard to top Equifax's breach/leak
| xp84 wrote:
| 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.
| Phil_Latio wrote:
| Maybe this specific exploit was already known for a long time to
| an illegitimate actor, because legit actors saw past rewards and
| simply gave up too early.
|
| $5000 (after complaining lol) really is a joke.
| PeeMcGee wrote:
| Wow, if I needed any more proof Google is a ghost ship then this
| is it. The $5K bounty is an insult, and the fact that they low-
| balled it in the first place makes them look like absolute
| clowns. Good on you for calling out how little of a shit Google
| gives about actually protecting user data.
| jcims wrote:
| Nobody is forced to participate in a bug bounty. If you don't
| like the rewards, don't do it. There's a limit to the financial
| viability of these programs.
| sjg1729 wrote:
| If the bug bounty program doesn't pay out much, there will be
| plenty of less reputable actors happy to pay more
| dns_snek wrote:
| Who's talking about participation? We can be appalled by
| their business practices as their customers (actual or
| potential). These are the same companies that tell us that
| our privacy and security is their #1 concern, and use that
| justification to take away our rights "for our own good", but
| when there's a real threat they address it with with a
| business-casual equivalent of "fuck off".
| miyuru wrote:
| TIL about another google product I knew nothing about.
| https://lookerstudio.google.com
| whalesalad wrote:
| You are blessed to have not been harassed by your GCP rep to
| attend a demo of this software.
| paxys wrote:
| Not a homegrown product. Looker was a pretty popular tool for
| data analysis and visualization and was acquired by Google a
| while ago.
| datadrivenangel wrote:
| Lookerstudio was formerly google data studio, which was
| homegrown at google!
| AtomicByte wrote:
| This is super creative and cool. Brutecat back at it again heh
| paxys wrote:
| Neat find, though it's funny to me that a phone number is
| something people (including everyone on this thread I bet) have
| been handing out like candy their entire adult lives - to
| friends, stores, banks, employers, government agencies, random
| websites - but still expect it to remain some critical secret
| that no one should ever find out. A phone number is about as
| private as your name, and you should consider it as such.
| beezlewax wrote:
| No it isn't. You give it to people you trust mostly you don't
| expect them to make it available publicly on the Internet.
| paxys wrote:
| You really trust that not a single friend of yours has ever
| clicked the "share contacts" button after downloading
| Facebook/Instagram/Snapchat/LinkedIn/TikTok...? You trust
| that your auto dealer or bank has not shared your details
| with Experian (even though you signed a piece of paper
| explicitly authorizing that)? You trust that your mobile
| operator itself isn't sharing your contact data with
| advertisers (go back and read your carrier agreement)? You
| trust that your grocery store's membership system has fool-
| proof IT security? Look up "recent data breaches" on Google
| and see how many of those companies/hospitals/government
| agencies you had a relationship with. I can guarantee that
| despite your best efforts and "trust" your phone number is
| accessible in a few clicks to anyone who cares to look.
| xp84 wrote:
| I feel like both sides are right here:
|
| 1. Google shouldn't make it trivial to find out my phone
| number from my email. Given that even Google itself,
| despite having better technology available, still allows
| the dumpster that is SMS verification to be used as an auth
| "factor," they should not be enabling SIM-swapping so
| directly. Just knowing someone's number makes it trivial to
| social engineer a SIM-swap, and that can likely unlock
| every account most people have, and a lot of important
| accounts (like banks) even for security-minded people,
| since banks love SMS and hate everything else.
|
| 2. I shouldn't act like my phone number is a well-protected
| secret, or trust that anyone who calls or texts me has
| gotten it from a trusted source.
| psunavy03 wrote:
| Uhh . . . this is not an earth-shattering take, considering
| they used to publish entire books with everyone's phone numbers
| and addresses in them, and you had to pay a fee not to have
| your number listed.
|
| Are we really to the point people don't understand the concept
| of a phone book anymore?
| jeroenhd wrote:
| Back when phone books were a thing, you couldn't take over a
| phone number from the other side of the country in the middle
| of the night and use it to transfer funds to a foreign bank
| account before you even wake up.
|
| Social security numbers were also never supposed to be secret
| but as their use changed over the years, so did the way
| people treat them.
|
| Yes, phone numbers are leaked everywhere. So are social
| security numbers and home addresses. That doesn't mean your
| website should be leaking that information.
| bornfreddy wrote:
| Things have changed in the last decades. With all the
| unsolicited calls (and especially scams) one would prefer to
| keep their phone number as private as possible. Doesn't mean
| that delivery can't get it, just that it shouldn't be on the
| net.
| sumtechguy wrote:
| Do I give it out? Not so much.
|
| Do I expect it to be private? No.
|
| You can for a small fee on some websites get my number.
|
| Heck if you find a phone book from ~2000 where I use to live
| then you could just look it up in the phone book. Number
| portability saw to that.
|
| Considering the number of data breaches and past history of
| phone numbers. To expect any sort of privacy is 'nice to
| have' but not going to happen. At this point it is basically
| security thru obscurity to expect it to be private.
|
| Even when they had 'unlisted' numbers you could buy a book
| from the phone company that had it in there anyway. They even
| had reverse phone books you could buy. I even remember CD's
| from ~1998 that had the whole country. You didn't even need
| to keep the books.
| prophesi wrote:
| This is why I use things like Firefox Relay's email/phone
| masking for sites and services I don't trust. Would be
| interested if people know of free alternatives, as the phone
| mask requires their premium plan, and that can be a no-go for
| friends and family.
| paxys wrote:
| It helps somewhat, but unless you give a unique number to
| every single friend, business, bank, store, your real number
| will find its way into data breaches sooner or later. Heck
| AT&T and T-Mobile have themselves had large scale hacks in
| the last few years.
| kccqzy wrote:
| > A phone number is about as private as your name
|
| Your name should also be somewhat private. No need to use your
| real name on the internet. There was a furor over Google
| requiring real names on Google+; this kind of outcry needs to
| continue.
| atum47 wrote:
| I did something similar way back when I was trying to find the
| phone number for a person, using Facebook.
|
| When recovering a password Facebook would give you most of the
| digits of the phone number, so I wrote them down in a vcard file
| and imported it on my phone to just look at the pictures. It
| worked surprisingly good.
| VladVladikoff wrote:
| There is also a similar hole with Google profile photos and
| other Google apps. For example if you see a review by John
| Smith on Google maps, you add emails on Google Hangouts, guess
| a bunch of variations like johnsmith@gmail.com,
| smithjohn@gmail.com etc and see the profile photos to compare
| the match.
| dheera wrote:
| This is why I don't use a real phone number with any of these
| services. They don't need my phone number to operate either.
| shwouchk wrote:
| 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?
| mystifyingpoi wrote:
| 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.
| bsammon wrote:
| Their own policies place a limit on how "demanding" they
| can be.
|
| Initializing a new (or power-washed) android/ChromeOS
| device _requires_ a Google account, so if you don't have
| one (or claim not to) they device initialization process
| will generate a new Google account for you. Even if there's
| no phone number or SIM card in the device.
|
| I've had a number of Android/ChromeOS devices over the
| years, and I've had each one generate a new Google account.
| None of these accounts have phone numbers associated with
| them.
|
| I generally don't use these accounts for much more than
| downloading free apps from the Google Play store -- maybe
| more extensive use would trigger a "You must add a phone
| number to this account to proceed"?
| megous wrote:
| They can just take your number anyway if you ever insert
| a SIM, since they control "your" phone.
| zerof1l wrote:
| 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.
| punnerud wrote:
| What if the user only get one address, how to separate the two?
| Seems like a need to share if a larger block (providor) is
| handing out based on blocks or single addresses...
| stackskipton wrote:
| 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 networks or same amount of IPv4
| address that exist.
|
| ARIN will hand anyone who asks a /48 IPv6 subnet which 65,536
| unique networks and getting larger prefix is not hard.
| growse wrote:
| > 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.
| stackskipton wrote:
| I'm talking practical. I know you can reduce networks
| further BUT there is plenty of stuff that could break.
| growse wrote:
| What stuff?
| stackskipton wrote:
| 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
| benlivengood wrote:
| I had assumed that most people would block by /64. Probably
| safest to count distinct abusive/noisy IPv6s per /64 and
| block/throttle when it hits a threshold.
|
| Ratio of abuse traffic per IPv6 from a /64 might also make a
| good threshold.
| stackskipton wrote:
| Rate limiting on /64 for IPv6 is well known and I know Google
| does it for other services. Sounds like this was not properly
| updated when they put IPv6 into play.
| AtomicByte wrote:
| Yes that does happen to be what is commonly done
| bscphil wrote:
| 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 your
| single-IP blocking for /64 blocking.
| Guvante wrote:
| It is already pretty common to start with IP blocking but
| upgrade to blocks when the bad behavior continues.
|
| Assuming a /64 as a starting point is an easy win and bumping
| it up with repeat offenders seems pretty easy in the grand
| scheme of things.
| bigstrat2003 wrote:
| 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.
| edelbitter wrote:
| 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.
| vladvasiliu wrote:
| 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.
| bsamuels wrote:
| IP rate limiting hasn't been a serious misuse prevention tool
| for 15-20 years
| demosthanos wrote:
| 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.
| markasoftware wrote:
| [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)
| madars wrote:
| 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.
| markasoftware wrote:
| they are pretty well-known as a "DMCA ignored" hosting
| site. Search "dmca ignored buyvm lowendtalk" and you'll
| find lots of forum threads of people recommending buyvm for
| hosting pirated content. They were also once mentioned by
| the RIAA for ignoring copyright law https://www.musicbusine
| ssworldwide.com/files/2025/01/USTR-20... There's also at
| least one mention I can find of them hosting a CSAM
| website.
| RankingMember wrote:
| > 2025-05-15 - Panel awards $1,337 + swag. Rationale:
| Exploitation likelihood is low. (lol)
|
| Oh, so _this_ is how vendors are going to start playing it to
| minimize bug bounty costs, huh? Good luck with that- the whole
| point of the award being a decent chunk of change is to make
| responsible disclosure more appealing to researchers who might
| otherwise go the other direction.
| xp84 wrote:
| I run the BBP at work and we have gotten great reports from it
| that I'm really glad we didn't find out the "bad" way.
|
| But I kind of think that, instead of any person or group of
| people choosing between "submit to a BBP" or "sell a 0-day to
| evil state actors or dark web clients" a BBP is better seen as
| allowing you to employ stunningly smart and ethical researchers
| in India (where a $2k bounty goes pretty far) to find all your
| vulns ASAP so that you have way fewer vulns for the actual bad
| guys to find. A pretty good "High" vuln is so valuable to
| people like CIA, FSB, Mossad, etc, not to mention terrorists,
| money launderers, etc. that it would be hard to compete with
| those guys financially if we were dealing with strictly
| economically rational but amoral researchers.
|
| We've paid thousands to a couple of the same researchers, and
| it's money well spent.
| VladVladikoff wrote:
| I'm mostly impressed that he can throw 40k requests per second at
| a server for a prolonged period and not somehow spike the
| resources enough to set off some alarms.
| kevindamm wrote:
| it is possible that it _did_ throw an alarm but the behavior
| ceased soon enough afterwards that it didn 't escalate to
| alert-level paging, or that -- even if it did -- those
| resources were back to normal within a few minutes that it took
| to open laptop, password password OTP, link-following and
| graph-referencing annnd oh it's already coming back down before
| the status update is drafted.
|
| And 40kqps isn't really much at the scale of Focus (or most of
| Google's APIs) so I could easily see it going under the radar,
| especially each using different IP addrs and with IPv6 across
| /64.
|
| The gap worth noticing here isn't monitoring, though, it's the
| zero rate limiting on js_disabled flow using a token borrowed
| from an earlier js enabled flow.
| amelius wrote:
| maybe he used a botnet for that? i.e. different IP address for
| every request
| helsinki wrote:
| These bug bounties pay peanuts. Sad.
| RankingMember wrote:
| They're only hanging themselves by cutting the bounties like
| this.
| garrettgarcia wrote:
| Anything under $100k for this is pathetic.
| EGreg wrote:
| 2025: https://qbix.com/blog/2025/06/06/%e2%80%9cno-way-to-
| prevent-...
|
| 2023: https://qbix.com/blog/2023/06/12/no-way-to-prevent-this-
| says...
|
| 2021: https://qbix.com/blog/2023/06/12/no-way-to-prevent-this-
| says...
|
| Which is funnier?
| cryptonector wrote:
| > 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.
___________________________________________________________________
(page generated 2025-06-09 23:00 UTC)