How improper OTP implementation could lead to Account Take Over (Part 2)

Previously, sample case related wrong OTP implementation during login process is found caused by two points:

It acted as only single passwordIt’s explicitly informed at API body response during OTP generation.

https://medium.com/@mmaulanaabdullah/how-improper-otp-implementation-could-lead-to-account-take-over-part1-7654d06e1a7a

It’s supposed OTP exchange must be properly carried out on all manner including login, forgot password, purchase etc. At this point, we are about to speak up about incorrect OTP application through forgot password flow. Generally, it should comply subsequent figure

OTP involvement during password forgot process

Unluckily, repetitive mistake happens due to explicit OTP number appears on API body response. Let’s run through how actually forgot password sequence occurs at this redacted.life.

OTP Verification UIAPI Get OTP Authentication

Based on the figure above, API /api/user/auth/get-otp is called right after user submit OTP verification request. Biggest blunder here is the body response include the password inside date parameter. Let’s try to input date password to the OTP verification prompt UI

OTP Verification Prompt UI

Boom !!! The next page that shows up is new password UI. Afterward, you might to create new password for victims phone number

New Password UIhttps://makeameme.org/meme/im-not-safe

It concludes that at this point in time, as long as you have other users’ phone number that is registered to redacted.life, you might act as him completely without having access through his/her device to read OTP.

According to observation, following points at redacted.lifewhich do not follow the rule of thumb:

OTP is included in body parameter responseThere is no maximum number of OTP regeneration for a specific userID (phoneNo) at specific range of time

Another case would be discussed at another article. Please kindly comment for anything you point out for wrong OTP implementation

To be continued..