Using Time-based One-time Passwords in Apigee Edge proxies

[dchiesa1]

Two-factor Authentication for APIs?

Two-factor authentication combines verifying something you know as well as something you have. For example, systems like gmail or twitter may use password based authentication (something you know) with one-time password token based authentication (something you have). Sometimes you'll see the acronyms 2FA or MFA (multi factor authentication) for this idea.

One-time Passwords

One-time passwords (OTP) are continuously-changing random numbers. They are generated by a device like a key fob or by an app on a phone and verified by a server. They can also be sent via email, SMS, push notifications, or phone calls.

A user registers the second-factor device during an enrollment process and confirms the setup by sending a sample one-time code. Upon confirmation, all future logins can prompt for an OTP. It is simple to use, and the security is not dependent on the sophistication of the user.

A common approach is to use a Time-based One-Time Password (TOTP). TOTP is just a formally-described way to generate one-time passwords based on a shared secret. You can read more about the algorithm in IETF RFC 6238.

How Does TOTP Work?

You're probably familiar with the user experience: Both the client (the app running on the mobile device, for example, or the keyfob) and the service provider share a secret. They use the current time to compute a TOTP value according to the algorithm described in RFC 6238. The client must send the TOTP and upon receipt, the server can confirm it. This constitutes the 2nd factor. If the TOTP presented by the client matches the TOTP computed by the server, then it proves that the user is in possession of the shared secret.

Setting up TOTP is pretty simple. Using an authenticator app on the phone, the user sees a 2-d QR barcode on the sign up screen. This barcode encodes a random secret generated by the server, just for that user. The authenticator app scans the code, it stores the secret and can then use it later to generate one-time codes via the RFC 6238 magic. The randomness of the secret is determined by the server and not controlled by the user. Obviously the server must also store the unique secret that is mapped to the user. This must be stored in plaintext, not hashed.

This is somewhat similar to password-based authentication except that the secret that is transmitted across the network is usable only for a 30-second interval, after which it becomes stale. So the window of vulnerability is much smaller than the case in which a never-expiring password is transmitted across networks.

In practice: If you are connected via a compromised wifi access point and transmit your password, it may leak and that password will be known by an attacker forever. On the other hand if you use TOTP, then the TOTP value will leak, but it will be useful only for 30 seconds.

TOTP is not supported out of the box with Apigee Edge.

You can implement TOTP today in Apigee Edge with a Java callout, available here.