How improper OTP implementation could lead to Account Take Over (Part1)
Login through On-Time Password (OTP) was long time ago introduced as it’s believed can act to augment existing userID and passwords with extra layer of authentication. Goal of OTP involvement here is to ensure that only an authorized person has access to resources (API/web page/etc). Following diagram is a good way how OTP is treated as 2FA (two factor authentication) :
At this article, a case would be run through as example of wrong OTP implementation. Found that at redacted.com how login is treated and could potentially lead to account take over.
Quick disclaimer: don’t do any harm against applications unless you have permission. This is meant for educational purpose only and share you the technique so that you can perform them against your own application(s) that you have permissions for.
Above figure shows that there is data parameter in response body which intuitively tells us about OTP in encrypted manner.
At a glance, code parameter in response body informs us that encrypted token from OTP input 345678 is “eDJ6MncyNzQ5NHoy” however to pass server’s expectation, it’s supposed “djI0M3IyMjQyNHQy”.
So by intercepting the request and modifying the response code parameter at Step 5 with data parameter at Step 1, the “true” authentication is able to be bypassed.
According to observation, following points at redacted.com which do not follow the rule of thumb:
- Authentication relies on OTP only as a consequence anyone could generate one for phone number they do not have
- OTP is included in body parameter response
- There is no maximum number of OTP regeneration for a specific userID (phoneNo)
Another case would be discussed at another article. Please kindly comment for anything you point out for wrong OTP implementation.
To be continued..