With the amount of confidential information stored online nowadays, the potential costs of a security breach are simply too devastating to ignore. Relying on traditional security mechanisms like single static password logins is no longer sound strategy. Organisations have turned to multi-factor authentication, which commonly employs the one-time password as a verification factor.
In this article, we’ll cover one-time passwords, as well as why they should be used and how you can test them in your application.
What is Multi-Factor Authentication
Multi-factor authentication is a way of proving to a system that you are who you say you are, by providing information that falls into more than one of the three factors (categories) of something you know (e.g. a password), something you are (e.g. your fingerprint), or something you have (e.g. your phone). Most multi-factor implementations require two of these factors, and so you'll often see this referred to as 2FA or two-factor authentication.
For a more detailed, and entertaining, description, check out this video by Tom Scott:
What are one-time passwords (OTP)?
You'll likely have used multi-factor authentication yourself when logging into your bank, where you will have typed in your username and password (something you know), then been asked to type in a 6-digit code generated by an app (such as Google Authenticator), or sent via SMS, to your phone (something you have). These codes are referred to as one-time passwords (or OTPs).
In most cases these aren't strictly single-use, instead they are valid for a very short period of time (typically between 30 seconds and 2 minutes), but the idea is that they are a password (or passcode) intended for one-off use for a particular secured action (e.g. logging in).
A few different algorithms exist for generating a one-time password and many of these are patented. The most common is the Time-based One-time Password (TOTP) which factors current time into the password generation process. This algorithm is standardised and described in detail in the RFC 6238 document.
Why perform OTP testing?
The clear reason to conduct OTP testing is to mitigate the potential for security breaches due to flaws in the security mechanism. You can perform OTP testing even if you only want to test the one-time password feature. As with all testing, there’s no silver bullet. But when testing security features like one-time passwords, it’s key to employ a testing strategy that’s comprehensive enough to cover every minute detail of the feature. Here’s what we have in mind:
- Testing your password to ensure that it adheres to your intended format. For example, does your password use numeric, alphabetic, or alphanumeric characters? Is your password in capital or lowercase letters, or a mix of the two? Is it case-sensitive?
- Testing your password’s expiry time. There’s a short window of time (typically no longer than 90 seconds) during which a password is valid. You might want to test if your password is usable within the intended time period or if your unused passwords expire on time.
- Testing password usability. A one-time password is intended to authenticate only a single session or transaction. Tests should confirm that this is indeed true.
- Other tests such as testing how your application handles multiple OTP requests by the same user or if a limit for how many OTPs may be generated holds.
These are common-sense tests, but depending on your application, you may also need to write more sophisticated tests.
Say you’re using an authenticator app that generates a password using an algorithm that factors current time into generation. This password, also known as a ‘shared secret’, is generated separately by the server and the app. Both sides are expected to generate an identical password that’s known only to them (hence the password’s name). A user is allowed to log in only if they present the password that matches the one on the server.
However, because the generation algorithm factors time into the generation process, it relies on the server and the app to be in sync. If the times are out of sync, the two sides will generate tokens for different timestamps and users will not be able to authenticate successfully. You probably do not want to invalidate a user’s code if it’s only slightly out of sync. Adopting a more lenient approach, you could allow codes from a few time steps before and after the correct one, or you could keep the code valid for longer. That said, you should take care to prevent codes from remaining valid indefinitely.
All of these are important considerations to take into account for OTP testing.
Even if you’re not developing and testing the one-time password feature itself, you may still want to conduct OTP tests as part of end-to-end testing. For example, if you’re testing logins, OTP testing is a mandatory hurdle you’ll have to work through.
How to perform OTP testing
One-time passwords are usually generated on the backend and sent via email or SMS. However, they can also be generated by a mobile application.
Testing outgoing emails and SMS is fairly simple. Depending on your needs and know-how, you have a host of DIY free options at your disposal.
However, if you’d rather offload the development work required to set up the various tools to start testing right away, a fully-hosted option like Mailosaur is your best bet. With its virtual SMTP and SMS testing servers and support for a variety of languages and testing frameworks, Mailosaur covers most testing bases. For example, with our SMS testing API, all it takes is just a few lines of code to retrieve your OTP password and continue your test.
You can see some of the most common testing scenarios in our documentation, for example testing 6-digit codes.
Testing SMS is very similar to the process above. Mailosaur would allocate you a number and you’d send your messages to the number rather than to an email address, with most of the code and the functionality remaining the same. Check out the documentation for email and SMS testing for more details on how to get started.
Testing OTP functionality with an app is a bit more complicated. One approach could be to implement the one-time password algorithm in code using something like GoogleAuth, a Java server library that generates TOTP passwords. Using GoogleAuth, you could generate a secret in your backend service, import the secret using GoogleAuth code, and validate that the code generates a valid TOTP 6-digit code.
There are various implementations of the TOTP algorithm available for different languages such as the ones for Go, Python, and PHP. If you’re looking for implementations in other languages, GitHub is of course the place to go: simply search for a standard like ‘RFC 6238’ and filter results by the desired language.
Start testing with Mailosaur!
We hope you enjoyed from our introduction to OTP testing, including our tips on how to conduct OTP tests.
If your application could benefit from OTP testing, our fully-hosted service makes testing a breeze.
Check out Mailosaur’s documentation to get started in no time