Skip to content

Instantly share code, notes, and snippets.

@suriya
Last active April 20, 2017 04:52
Show Gist options
  • Save suriya/2d231bddc9cbd1781eaec7d7fe4085ff to your computer and use it in GitHub Desktop.
Save suriya/2d231bddc9cbd1781eaec7d7fe4085ff to your computer and use it in GitHub Desktop.
Security issues with GST Network's Authentication API

Security issues with GST Network's Authentication API

One line summary. GSTN's use of OTP for authentication is not very secure. GSTN should use a standard like OAuth

The GST Network's (GSTN) version 0.2 draft API propose using a One-Time Password (OTP) for a Software to authenticate on behalf of a Tax Payer (user). The design of the Authentication API is documented here. The Authentication API is well designed to ensure that data communicated between any software and GSTN in secure.

However, the API uses an OTP to authenticate software on behalf of a user. Here is a relevant quote from the API document.

Authenticating the Tax Payer essentially means authenticating the Primary Signatory established at the time of registration of the Tax Payer (GSTIN creation). Unlike traditional userid/password models, GST System APIs proposes to accomplish this task through a one-time-password (OTP) sent to the registered mobile number or email id of the Primary Signatory.

From an API perspective, this translates to two calls - first call for a request for OTP and a second call to submit the OTP. The OTP submitted in the second call needs to be encrypted to protect the session. The OTP will be encrypted using a symmetric key already called the app-key exchanged. The concept of the app-key is described in the subsequent section.

The end result of Tax Payer authentication process is to establish an authorization-token for the session which needs to be included in the header for all subsequent API calls.

OTPs protect well against impersonation in Multi Factor Authentication (MFA) schemes, where a user first performs an action and is then required to authenticate themself further using an OTP sent over SMS or E-mail. For example, when logging into a website, or making a making a online transaction, the user first initiates the action and provides the secret they know (password or credit card number). In response to their action, the system further requires OTP authentication proving that the user has their phone with them.

In the case of the GST Network, we have a Single Factor Authentication scheme that uses OTP. An OTP sent over SMS or Email is not very secure (with Email being worse than SMS). In fact, the National Institute of Standards and Technology (NIST) has deprecated OTPs over SMS in MFA schemes. That being the case, using an OTP as the only means of authentication is highly insecure.

Recommendation

GSTN should use standard means of authorizing software on behalf of users. The most common method in use is OAuth 2.0. Millions of users have used this method to log in using their Google, Facebook, Twitter, or other accounts (OAuth provider) to login to various websites. OAuth performs authentication/authorization in two directions. First, the OAuth provider authenticates to the software or website that the user is who they claim they are. Second, the user authorizes the software or website to represent them to read data from or write data to the OAuth provider. Moreover, the user can control exactly what rights the software has. For example, a user could control whether a software could simply know the user's email address, or could it actually read all emails? Could the software send emails on behalf of the user?

Adopting OAuth 2.0 would allow a user to control the software that they are using in a fine grained manner. The user could use one software for analyzing their tax returns data, providing the software with read-only permissions. The user could use another software for actually filing their tax returns.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment