ルカ-さん Luca-san

How to evaluate security problems

Our security team provides support to other lines of business and can be contacted about any security-related issue. Recently, the product and development teams asked about SMS OTP which was a great chance to show how we approach these requests. The hint is threat modelling, which I plan to cover in a dedicated blog post one day.

Table of Contents

The Problem

OTP (One Time Password) time out and industry standard.

Hello security,

we wanted your input about best practice for our OTP product. We currently offer phone number verification through OTP via text message. When these code are sent, they are deemed expired after 60 seconds (currently config) but we do have cases of users being a bit slow with this and we were wondering whether you think 60 seconds is too low, or legitimate by industry standards for such an SMS verification as we currently considering increasing this timeout expiration. This is ultimately a product decision but we are gathering your team feedback here before handing over the decision. Feedback much welcome

This is a rephrased version of the message we got in our Slack channel from a lead dev, asking us to evaluate a security concept. You might not be familiar with the topic or know enough to provide any input, so how do you answer? If you want to take the correct approach and not just decide an arbitrary number based on your feelings, ask yourself why we need a timeout? and you'll be on a good start. You need to start by researching the topic to gain a solid understanding (that's in general, something higher ups managers should learn one day) and in security, for such cases, that research leads you to perform a threat modelling exercise.

Threat Modelling

Threat modelling is a process by which potential threats, such as structural vulnerabilities or the absence of appropriate safeguards, can be identified and enumerated, and countermeasures prioritized. The purpose of threat modelling is to provide defenders with a systematic analysis of what controls or defences need to be included, given the nature of the system, the probable attacker's profile, the most likely attack vectors, and the assets most desired by an attacker.

Walkthrough

Because we’re not building a completely new feature and know the context, there’s no need for a full threat model, we can concentrate on the security concerns around the OTP and why we need a rate limit as both are standard practice.

Industry Standards

My first step is to consult official guidance; in my experience, NIST and OWASP (for application security) are the most helpful. Using those standards saves time and gives you a strong rationale with auditors, customers, or colleagues which is way better than “it’s just my opinion.” I’ll write a longer post on this one day, but for now let’s keep moving.

NIST

There is no specific guideline on SMS OTPs but NIST guidelines on OTP (section 5.1.4.1 here) recommend maximum 2 minutes:

If the nonce used to generate the authenticator output is based on a real-time clock, the nonce SHALL be changed at least once every 2 minutes.

OWASP

OWASP does not specifically mention a limit, but only that hardware/software OTP are typically valid for 60s.

There are other standards but i couldn't find them mentioning specific values for OTPs, so nothing else we can use in our reasoning. Let's move on to actually understand the problem.

Understanding the problem

Why we need an expiration?

The lifespan of an OTP is there only to protect guessing and bruteforce of the value itself (and to a lesser extent, its reuse when no dedicated control exists). Choose an expiry so that it is statistically improbable an attacker can guess or bruteforce the correct value during its validity window.

Are there any other countermeasures?

Yes, in our case we also have both rate limit (max 3 attempts) and anti-replay (the value is only valid once).

How long is the OTP?

The OTP length determines guessing/bruteforce resistance. We currently use 6 digits (a common SMS OTP length) but our developers plan to increase this to 10 digits, which will substantially raises the attack cost.

Calculate the risk

It's not necessary in this specific case, but you can actually do the math to estimate bruteforce risk. A 6-digit numeric OTP has 1,000,000 possible values and with three tries the success chance per OTP is 3/1,000,000 (0.0003%). Throw an average network latency value in the mix, and you can calculate how little is the risk for this exploitation - even without considering that an attacker must first get to point of having to bypass the OTP.

Audits and Customers

Conversations with auditors and customers can be difficult because they sometimes request insecure or outdated configurations based on their playbooks. A common example is mandatory periodic password rotation and strict complexity rules, which are proven to reduce password security.

But how do push back, as we know those conversations are...difficult, to say the least? It helps to have standards on your side. NIST comes to our rescue here, as we can point them to the NIST Special Publication 800-63B on Digital Identity Guidelines, Authentication and Lifecycle Management. From section 5.1.1.2 Memorized Secret Verifiers:

Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

With this, you can push back with confidence. Otherwise it's your opinion vs customer/auditor and good luck trying to convince them.

Consider how decisions that don’t materially increase risk (for example in this case, a longer OTP timeout) may still trigger pushback from auditors or customers, so prefer industry standards when possible.

Outcome

With the gathered information, we can recommend a value to developers. I proposed increasing the OTP timeout to 2 minutes because this maintains security and is straightforward to defend using NIST guidance, but I advised against anything longer as it becomes harder to justify.

While this example was simple, for less clear cases seek peer review (other members of the security team) to challenge assumptions and double‑check your logic. Have someone play the devil's advocate is extremely helpful.

Recap