It's interesting to wonder why only 5M accounts were affected by this exploit, especially if it's brute forceable. IIRC this vulnerability was widely known about for at least months before it was fixed, so I can't imagine nobody in the know had access to the resources/botnets necessary to enumerate through every account.

Have only 5M accounts linked their phone numbers on Twitter? That's less than 2% of their total accounts (~290M). I don't know what the industry average is for linking phone numbers, but this seems like an exceptionally low ratio.

5,000,000 seconds is about two months. The attackers simply might not have had enough time to check more numbers than that.

(Assumption: They were checking only one number per second, either to avoid detection or because they were rate-limited.)

What percent of mobile numbers do you think are associated with twitter accounts? I don’t know, but it wouldn’t surprise me to find out they had to try 500M or more numbers to find 5M accounts.

We'd need to actually test it. But I believe the finding ratio would be even lower than 1 in 100.

As of Dec 2020 only 2.3% of active accounts had any form of 2FA enabled [1]

[1] https://www.bleepingcomputer.com/news/security/twitter-revea...

Phone numbers in the US. In other parts of the world, they're longer.

International phone numbers can be up to 15 digits, but in most places the rules narrow them down further.

For example in the UK the country code is 44, all mobile phone numbers start with 7, with 9 digits after that.

And all US numbers begin with 555, or so I’m lead to believe.

It's absolutely true. All US numbers are 555-xxxx. You can see this in any US movie or TV show, which we know to be very accurate.

Similarly, any time an American car has a fender-bender, or at least one of its wheels leaves the ground, it explodes in a massive fireball.

That's what's really holding me back from getting an American car. Just fearing that somebody might hit my car and then it's over.

Independent of Hollywood, some American cars just might do that. Maybe not in such an impressive manner, but I've been through so many Dodge transmissions and Ford's reputation here is even worse.

joking aside, the 5M figure probably came from targeting like this, such as choosing a few area codes with high tech populations and testing the ~10M phone numbers for each area

Us and Canada, remember we (Canada)helped invent the phone systems

So?

Maybe Musk is right, they are all bots.

Maybe Musk is behind this to weasel out of the contract?

Yes he certainly is; he also reported it afterwards via HackerOne to get that $5k bounty. Two birds one stone.

If Musk is right, it's not weaseling out of contract.

Rate limiting should be used to mitigate this, although I suppose a botnet could overcome that to some extent proportional to the size of the botnet.

And for anyone who didn't read TFA, this incident goes well beyond leaking what phone numbers use the product, it leaked the usernames associated with each as well.

Rate limiting is not useful meaningfully. For a service we ran we regularly had botnets with 100k+ IP addresses making one request an hour to endpoints, which absolutely decimated the backend but hit no limits at all that a real user wouldn't also trigger. Even with a couple of requests an hour you could enumerate the entire phone number space in a very short period with that botnet.

Out of curiosity, how does someone possibly get 100k+ IP addresses? I had enough trouble getting 1 public IP address.

People build botnets by enticing people to install trojans on their computers, e.g. a free utility app or game.

They can then earn money from people who want to rent access to these botnets.

There are also free VPN services who, in their fine print, say that users grant them permission to route other traffic via their connections.

There are "residential proxy services" offering exactly this and you only ever pay for bandwidth. Using 100,000 unique non-datacenter IPs will only cost you few thousand dollars as long as you only sending tiny API requests.

And this is service offered by registered Israeli company that get formal agreement from "bots" to route traffic through them. Very shady, but totally legal service that used by a lot of data collection agencies for price tracking on Amazon or getting data from Linkedin, etc.

botnets. With all of the crappy IoT devices out there it is even easier to get inside of consumers networks.

How do you defend against such an attack? Putting a service behind something like Cloudflare won't bring it down but it will still leak the phone numbers existence, no?

Don't leak whether or not the phone number belongs to an account. All failed login attempts should be some form of "Invalid login" regardless of whether or not it was an attempt against an actual account or not.

Also worth noting that time response deviance when user exists or not can also be a leak of info

Usually you'd try to make the effort/cost no longer worth the data with minimal user impact. For instance, text/email the inputted address with the result instead of displaying it to the requestor through the browser

Or if this functionality needs to return the value, require an authenticated user and impose rate limits based on reputation (which could just be account age)

For instance, Facebook and Twitter used to tell you which profile a phone number belonged to when you put it in the search box (maybe it was this issue). You could restrict that to authenticated users that were 30 days+ old and impose rate limits per day on top of that. A regular user could still look up a few numbers per day but someone enumerating phone numbers would need lots of 1 month old accounts (more effort/cost)

I guess I was thinking more like "limiting the number of attempts" than "limiting the number of attempts over time" -- take time out of the equation (but then NAT causes trouble). But even so, you're right: as the threat landscape approaches the size of the result set, it breaks down no matter what.

That has some problems. If you limit the total number of attempts globally then the feature is effectively disabled, every botnet and script will blow through the attempt budget and real users can't use it. Global limits and IP address limits are not useful, and because we're assuming the user is unauthenticated (using the password reset), we have no other way of distinguishing good traffic.

Captcha comes to mind, but that's a cat-and-mouse game in the age of machine learning (not to mention actual humans working for a bad actor). Cloudflare seems to be on the cutting edge with their newest challenge mechanism, but good vs bad is somewhat distinct from human vs script.

My wife was in charge of security at MySpace back when MySpace was still a thing and there was one occasion that the MySpace team was manually feeding images to a suspected human acting as a bot. As I recall it became clear to both sides that there were humans on the other end and it ended with a picture of a scantily-clad woman and a response of “very funny.”

Solving a few thousand captchas an hour costs you like 200$ per day. Forget about it if someone is dedicated.

It's a solved problems that you never confirm or deny the registration of an identity (like email or phone) for your service.

Bad login? "Not a valid user/pass combo"

Password recovery? No matter what email or phone provided, simply say "If the email matches our records, we will send a recovery link".

What about new user sign up? Most systems will tell you if an email address has already been registered (and it seems hard to get round that).

You can always show that message after email is verified. Don't reveal information without verifying the ownership of email or phone number.

Until the UX team comes in and demands "better error messages".

Possibly, but a good org will empower security teams to make that call and collaborate with UX on a safe compromise.

In the USA.

They range from 4 (St. Helena) to 13 (Austria), I believe.

It's typically smaller though, not every phone number is allocated and many are in sequential groups. Some are special cased, you don't need to search any number matching `****555***` in north america for example, which cuts down on the search space quite a bit.

"Quite a bit"? Filtering out ***555**** removes only 0.1% of phone numbers ;)

That's one example of an invalid range, not all of them. Lots of the area codes in north america just haven't been used for one reason or another.

I didn't do the math here but: Filtering out 5*... would remove 10% of the search space. (dots mean "followed by more stars")

Filtering out *5*... would remove 1%. So wouldn't ***555**** remove closer to 0.01%, not 0.1%?

Try the math, this is a good problem to work through. The position of the 5 doesn't impact the search space like that. 10% of the 10 digit numbers start with a 5. 10% of the 10 digit numbers end with a 5. 5... in your example shouldn't be 1%.

St Helena changed to 5 digits nearly 7 years ago.

Maybe they should store salted hashes of phone numbers.

The purposes of phone numbers:

1. Verify you are a not a bot: no need to store anything except TRUE once verified.

2. 2FA - well use something better than SMS, but if you must, store the hash, and make me enter my number for the 2FA each time. Compare with hash and then send SMS.

Didn’t downvote and think your idea is reasonable, but worth noting that twitter currently needs unhashed phone numbers for:

- Account search during password recovery (lets users search for their account by phone number): https://twitter.com/account/begin_password_reset

- User discoverability and account recommendations (users who upload their address books can find others by phone number, users who share their number can be found by others): https://help.twitter.com/en/using-twitter/account-suggestion...

Hashing numbers has other implications, like support impact (some folks don’t know their own phone number), preventing the ability to offer SMS updates in countries that need it (or to reactivate that feature in national emergencies for countries that SMS support was pulled from), as well as making potential marketing, data mining, satisfying legal requests, and future feature development harder.

So your suggestion is a good one for a privacy-conscious service that doesn’t already depend on (or that is unwilling to relinquish) unhashed numbers, but it probably isn’t in the nature of twitter to seek to protect user data at the expense of existing or future features, even after leaks like this.

Not to mention that only having salted hashes will make it harder for them to link your advertising profile with other data brokers.

Non-geeks dislike the hassle of 2FA enough as it is, having to enter their phone number every time too sounds like it would hurt adoption quite significantly.

With technology like FIDO Passkey built into newer phones (both iOS and Android), I see passwordless multi-factor attested auth becoming the standard for most services very soon. Then, users will have to do even less to get more security.

Downvote explainer?

CPU throughput =/= endpoint throughput

already doable with e-mail addresses. doing this with just a phone number is not really a problem. It is a problem when you can link the phone and email. But discovering a phonenumber in itself is nothing more then pressing random numbers and see who answers?