Why Email (and SMS) Verification Codes Expiring After a Few Minutes Are a Bad Idea and Simply Wrong

Many online services ask users to enter an E-Mail address and then send a verification code that expires after five or ten minutes. While this approach is unfortunately widespread, it relies on an assumption that the underlying E-Mail infrastructure was never designed to guarantee - or rather to say that is simply wrong: rapid delivery.

The Internets E-Mail system was built to prioritize reliability over immediacy. According to RFC 5321, the current SMTP standard, mail transfer agents encountering temporary delivery problems are required to retry delivery attempts over extended periods of time. The RFC states that:

“the give-up time generally needs to be at least 4-5 days.”

In other words, the protocol itself explicitly requires that a message may remain undelivered for several days at least before being considered permanently failed. Temporary failures are not exceptional events either. They are part of the normal operation of E-Mail systems. A receiving server may respond with temporary error codes indicating that delivery should be attempted again later. Examples include:

• The destination server is temporarily overloaded.
• Maintenance, like software upgrades or migrations, is being performed.
• A spam filtering system applies greylisting and intentionally rejects the first delivery attempt over tens of minutes.
• Storage resources are temporarily exhausted.
• Network connectivity problems exist between providers. This is way more common than people would expect.

In all these situations, the correct behaviour of a compliant mail server is to retain the message and retry delivery later. The result is that SMTP provides eventual delivery, not timely delivery.

Yet many websites issue verification codes that expire after only a few minutes. Such systems implicitly assume that E-Mail behaves more like an instant messaging service. Unfortunately, no such guarantee exists within the E-Mail standards. Many times the E-Mail arrives quickly so people believe this mechanism works and is valid. However, the fact that rapid delivery is common and happens often does not imply that it is guaranteed or the solution is valid. A user whose provider temporarily delays delivery may receive a perfectly valid E-Mail containing a code that has already expired by the time it reaches their inbox.

From the user’s perspective, this often appears as if the website is malfunctioning:

“I received the code, entered it immediately, and it had already expired.”

Technically, from the E-Mail point of view, neither side necessarily behaved incorrectly:

• The website sent the E-Mail.
• The mail servers followed SMTP standards.
• The user’s provider eventually delivered the message.

The failure lies in the assumption that a protocol designed for asynchronous communication can reliably support time-critical authentication workflows. This is particularly problematic because users have little control over the mail infrastructure involved. Delivery may depend on multiple independent systems operated by different organisations. If E-Mail must be used for verification, expiration periods should account for the characteristics of the transport medium. Verification links or codes valid for several weeks, combined with mechanisms to invalidate previously issued tokens once used, generally provide a better user experience than codes expiring after only a few minutes.

Alternatively, time-sensitive authentication should rely on mechanisms specifically designed for immediate use, such as authenticator applications implementing TOTP or hardware security keys.

Email remains an excellent medium for asynchronous communication. It was never intended to function as a low-latency authentication channel.

Why SMS Is Also a Poor Choice for Short-Lived Verification Codes

Unlike E-Mail, SMS messages are transported through the mobile network infrastructure defined by the GSM, LTE and later 3GPP standards. Despite their widespread use for two-factor authentication, SMS messages share an important characteristic with E-Mail: they are fundamentally based on a store-and-forward architecture. And always keep in mind that our mobile networks (and usually also all current smartphones) are inherently unsecure.

When an SMS message is sent, it is usually transferred first to a Short Message Service Centre (SMSC). The SMSC then attempts to deliver the message to the recipient’s device. If the device is unreachable, the message is retained and delivery is retried later. The relevant technical specifications explicitly support this behaviour. In particular, the GSM specification and its successors define a Validity Period, describing how long a network is permitted to retain a message while repeatedly attempting delivery.

The exact retention period depends on the sending configuration and the policies of the involved mobile network operators. The standards do not impose a universally applicable upper limit that guarantees delivery within a specific amount of time. Temporary delays can occur for many reasons:

• The recipients phone is switched off.
• The device is outside the coverage area of the mobile network.
• The device is roaming between operators.
• Signalling infrastructure experiences temporary congestion.
• Inter-operator routing problems occur.
• Delivery is postponed until the recipient’s device becomes reachable again.
• Mobile network load is high.

Under such circumstances, delayed delivery is not necessarily an indication of malfunction. Rather, it is a consequence of the store-and-forward model upon which SMS was designed. Consequently, SMS does not provide deterministic timing guarantees. The standards governing SMS transmission were developed to maximise the likelihood of eventual delivery, not to ensure that a message arrives within a narrowly defined time window. Nevertheless, many online services rely on SMS messages containing verification codes that expire after only a few minutes. Such systems implicitly assume that the underlying communication infrastructure behaves as a real-time service, even though the standards make no such promise. This is simply a wrong assumption.

As with E-Mail, this creates a situation in which all participating systems may behave entirely as intended, while the authentication process still fails:

• The website generates and transmits the verification code.
• The mobile operators process and route the message according to their specifications and policies.
• The recipient eventually receives the message.

Yet by the time the code becomes available to the user, it may already have expired. The resulting failure is therefore not necessarily caused by a defect in the communication infrastructure. Instead, it arises from the mismatch between the characteristics of the chosen transport mechanism and the assumptions made by the authentication system built upon it.

SMS remains an effective (non deterministic and non confidential) technology for asynchronous notifications and person-to-person communication. However, systems that depend on extremely short validity periods for authentication tokens should recognise that SMS was not designed to function as a deterministic, low-latency delivery channel.

Conclusion

As shown above the usage of codes that are valid for less than a few weeks is invalid for E-Mail and SMS. The consequence is very simple: Do not use codes that are transmitted via those channels. If you want to have real-time two factor authentication use appropriate techniques:

• TOTP token generated by applications or hardware generators
• Hardware security modules
• One time TAN lists

In addition do not try to evade the problems using mobile phone apps. Keep in mind mobile phones are as of today inherently unsafe platforms that should never be used for any valueable or confidential applications. And keep in mind: Just because everyone does it (or even government organizations do it) it is not correct or trustable.

References

• RFC 5321: Simple Mail Transfer Protocol, the current version of the transfer protocol for E-Mail
• Greylisting on Wikipedia
• 3GPP TS 23.040: Technical realization of the Short Message Service (SMS)

This article is tagged:

• Programming
• Basics
• Security
• How stuff works
• System administration
• Administration
• Web
• Computer
• Internet