Hacker News Reader

Comment by GhostVII | Hacker News Reader

Using a phone number for password reset seems like a terrible idea in general, especially if you have SMS-based 2FA. Phone numbers are way to easy to social engineer, and if your second factor can reset your first one, you don't have 2FA.

Also if I am reading it correctly, it sounds like the rate limiting was being done per-IP, which sounds strange. Why wouldn't Instagram just allow a fixed number of tries (some low limit, like 25) from any IP before invalidating the code? I don't really see a scenario where it makes sense to have per-IP rate limiting here. I guess they are probably just using the rate limiting features which are built in to whatever framework Instagram is using for their API.

View on HN

> Also if I am reading it correctly, it sounds like the rate limiting was being done per-IP, which sounds strange.

Seems to me that the main mistake was not rate limiting per account right? If you get 200k password requests for a single user something is severely wrong.

Or maybe they did and it didn't work, he makes reference to a race condition in the original post but doesn't elaborate.

Likely this is to prevent malicious attempts to block access to an account- I can definitely imagine someone trying to block a popular account by abusing the password reset mechanism. Imagine attempting to reset a password of a popular account by spamming the p/W reset mechanism, if the limit is per-account instead of per-IP then you could fairly easily deny access to any account.

How would you be denying access? The block is only by the password reset system, if you know the password you can still access your account.

He didn't really explain it, but I think what was going on is the rate limiting is done per account, and the race condition was a way to circumvent that. He has to make all the requests very quickly because the first thing all the requests are doing is determining if new requests for this account should be ignored. All the requests are received around the same time, they all make this check and decide they are valid requests, then they all report that an attempt was made for that account (locking it).

The rate limiting for IPs is probably global (not related to the reset endpoint).

I think you are dead on, yeah it’s the quick rate of large numbers of requests that avoid the per-account rate limiting. Curious how they resolved this— run all authentication requests for a given user serially and in a consolidated fashion at some point. Exclusive lock the relevant db record before checking the code and recording the failure?

Yeah, my first thought was make every attempt acquire some per user lock with a timeout. It's pretty much the same thing. Either one would have a negligible effect on legitimate requests and would solve the problem.

Could start by incrementing the value, then checking if it's below the threshold, similar to an atomic fetch_add operation. PostgreSQL has RETURNING clauses, SQL Server has OUTPUT clauses, etc...

You could pipe the requests into a FIFO without back pressure so excessive requests are dropped by default.

Distributed rate limiting is hard. He could hit multiple front ends simultaneously before they have a chance to catchup to the correct counts.

Yeah it is hard. The enforcement would need to be done on a single backend. Not all users need to have their auth done by the same specific backend, but each user individually should always have their auth go to the same backend (or same concurrency domain, if distributed locking applies to the architecture).

If you use a sharded “eventual consistency” database cluster to store the number of reset attempts per interval, then sufficient IPs can be purchased to overwhelm your “eventual” threshold unless each reset attempt compels consistency before evaluating whether the limit is reached. That would qualify as a “race condition” in language terms, even if not being the classical sort of one considered such by programmers, and present the easy described fix (take a consistent read lock rather than an inconsistent one or none at all) when checking the rate limit.

Also for people who don't have mobile phone signal at home (hello us), it's almost impossible to use these 2FA systems. There are a few systems including the UK government's own "Verify" scheme for submitting tax returns that I quite literally cannot use.

Not that mobile phone 2FA is actually secure. Fraudsters in the UK have discovered that it's possible to take over phone numbers rather easily because that relies on the phone companies' own systems which are (predictably) insecure.

A lot of carriers support wifi calling. You should see if yours done and turn it on.

I still don’t think an actual SMS would be received.

SMS is old-school. That thing is going via the tower or it’s not going at all.

(This is just a hunch. Happy to be told I’m wrong!)

My understanding is that "WiFi Calling" involves having your phone set up an IPsec tunnel (authenticated by your SIM) with your carrier, and then transferring essentially the same packets over that as would be transferred to the cell tower. I think that includes SMS traffic along with everything else.

(IIRC, the 3G and LTE versions of the tunnel carry traffic at different layers of the protocol stack, but in both cases being able to handle SMS and similar non-Internet features is part of the goal. As is being able to handoff between wifi and cellular transports in the middle of a call — I have no idea how well that works in practice.)

SMS will be received. It is just like being on the normal cell network.

Some Verify providers have a provision for token based 2FA. I used the Post Office for my account with standard TOTP.

Or people who change phone numbers for any reason or even travel.

If 2FA decides to kick in then, your account is effectively dead with most companies until you regain access to your old phone number.

I lost my Uber account to this after I logged in on a prepaid SIM while traveling and didn't reset it before tossing the SIM

> Why wouldn't Instagram just allow a fixed number of tries (some low limit, like 25) from any IP before invalidating the code?

This could makes it very easy to perform a DOS attack against a user. You could constantly send failed attempts and make it impossible for the user to type in the real code before you invalidate it.

Add a captcha then.

Still not hard to manually DOS. And to do it at scale you only have to pay 2.5 cents per invalidation.

well you can't dos a user forever. and it's quite impossible that somebody knows that a user lost it's password and DOS's the reset mechanism.

I have turned off phone 2FA on all services that permit me to do so after getting hacked by someone using that exploit. Typically I use Google 2FA via Authy or Authy itself

you should be aware that Authy can by default be taken over with just your sim card. I believe with the right settings you can disable this behaviour

Yes, you have to disable “multiple devices”. You just have to remember to re-enable it if you want to install Authy on a new phone and reinstall from backup.

I've been considering getting a second, secret SIM card exclusively for use with services where SMS 2FA is the only option.

I've been using Google Voice for that purpose for years, and it has been perfect. The phone number that is for 2FA only, shouldn't be as easy to social engineer your typical telcom, since it is all controlled from within my Google account, and I get immediate security notifications if something fishy is up.

That's a great plan, and it definitely reduces your risk to being exposed to SIM hijacking. Unfortunately, I suspect services that enforce poor security standards are probably not following best practices in their backend either. This means your secret number stops being secret if their database ever leaks.

It's still better than using the same number as you use for everything else, but it's important to understand the caveats.

This is standard practice for public figures like YouTubers who often get griefed

> Google 2FA via Authy

"Google 2FA" is TOTP, an open standard, not a Google produced solution.

https://tools.ietf.org/html/rfc6238

Thanks for the clarification. I knew it was open-source, didn't realize it was an RFC.

I used to work at a cell phone company. One day I needed to change my SIM card so I call up the help desk :

"Hi I have a new SIM card, can you please activate it?

— Sure what's your number and IMSI?

— My number is ..., the IMSI is ...

— OK done"

And so, just like that, I took over someone else's phone number. Not on purpose, but the guy made a mistake punching in my number, didn't verify my identity, and ended up assigning someone else's phone number to my SIM card. I called the guy back after realizing that I wasn't getting calls and that the people I called thought I now had a new number.

Granted it was a while ago but the experience gave me a very low opinion of SMS for 2FA.

Friend of mine walked into a mobile phone store to do pretty much the same thing and he was also extremely surprised that they didn't ask for any extra info or ID. He did get the correct number, though :)

The first type of attack that should come to mind with SMS-based 2FA is SIM cloning. Identity question answers can be purchased off the dark web from previous leaks. Also, social engineering is notoriously effective against several of the top carriers, who lack effective identity validation. Lives have been ruined.

Reply on news.ycombinator.com