Hacker News Reader

Comment by lima | Hacker News Reader

> They don't explain it, but I'm assuming that the API is something like api.cercadating.com/otp/<phone-number>, so you can guess phone numbers and get OTP codes even if you don't control the phone numbers.

They mention guessing phone numbers, and then the API call for sending the OTP... literally just returns the OTP.

View on HN

Yeah, I guess there's no reason for the API to ever return the OTP, but the severity depends on how you call the API. If the API is `api.cercadating.com/otp/<unpredictable-40-character-token>`, then that's not so bad. If it's `api.cercadating.com/otp/<guessable four-digit number>` that's a different story.

From context, I assume it's closer to the latter, but it would have been helpful for the author to explain it a bit better.

Hi, author here! My bad if that was not clear. The endpoint was just a POST request where the body was the phone number, so that is all you needed to know to take over someone's account.

I think it could be a tad bit clearer. I understand what you are saying but this thread requires reading multiple messages, parsing out the wrong parts, and putting together the correct ones to fully understand.

Put very simply, they exposed an endpoint that took a phone number as input to send a OTP code. That's reasonable and many companies do this without issue. The problem is, instead of just sending the OTP code they _returned the code to the client_ as well.

There is never a good reason to do this, it defeats the entire purpose. The only reason you send a code to a phone is for the user to enter to prove they "own" that phone number.

It's like having a secure vault but leaving a post-it note with the combination stuck to it.

Reply on news.ycombinator.com