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

91–100 of 204 posts

Re: Bruteforcing the phone number of any Google user

#91

Post by snmx999 »

valicord wrote: post #86
dylan604 wrote: post #59

Earlier quoted context omitted.

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.

How does a new hire know "what it is supposed to be"?

The information is transferred through a method called "communication" by another human.

Re: Bruteforcing the phone number of any Google user

#93

Post by dylan604 »

snmx999 wrote: post #91
valicord wrote: post #86

Earlier quoted context omitted.

How does a new hire know "what it is supposed to be"?

The information is transferred through a method called "communication" by another human.

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.

Re: Bruteforcing the phone number of any Google user

#95

Post by IAmBroom »

reaperducer wrote: post #35
staticshock wrote: post #16

Earlier quoted context omitted.

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.

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

"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!"

Re: Bruteforcing the phone number of any Google user

#96

Post by delroth »

okanat wrote: post #53
paxys wrote: post #21

Earlier quoted context omitted.

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.

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

Re: Bruteforcing the phone number of any Google user

#98

Post by stackskipton »

punnerud wrote: post #67
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.

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…

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.

Re: Bruteforcing the phone number of any Google user

#99

Post by bornfreddy »

psunavy03 wrote: post #44
paxys wrote: post #41

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 su…

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?

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.

Re: Bruteforcing the phone number of any Google user

#100

Post by mmsc »

xivzgrev wrote: post #23
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…

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.

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"
Post reply on HN