Your OTP isn’t a One-Time-Password any more. And that carries a security cost

Start with what each instrument is actually for, because they answer different questions. A PIN authenticates a person; it says that whoever offers it knows a secret belonging to the account. A one-time password authenticates an event; it says that this specific booking, made moments ago, is the one this driver is about to begin. That distinction carries real weight, and three properties follow from it that no fixed number can reproduce.

The first is scope. An OTP is valid for a single booking, and only while it is live, so the same value is never correct twice. A PIN is correct for every ride an account will ever take, so it carries no information about which ride is which. It cannot tell apart the trip you booked from a trip booked in your name by someone else, because both produce the same number.

The second is resistance to replay. An OTP is spent on use and expires when the trip begins, so a number overheard in a queue or captured in a screenshot is already worthless. A PIN cannot be spent; reuse is its nature. This induces a deeper difference about threat actors: An OTP is built for a world in which the driver is an untrusted party – he receives the number on every ride but gains nothing durable from it, because the code dies the moment the trip starts. A fixed PIN inverts that assumption. The same person now receives, on every trip, a secret that keeps working, and the rider’s safety comes to depend on his choosing not to retain it.

The third is freshness. Because an OTP is generated at the moment of booking and delivered to the rider separately, producing the correct one is evidence that its holder is the person who just booked and is present right now. A PIN shows only that someone, at some unknown time, learned a permanent secret, one that can be memorised, shared, or dictated over a phone call.

These three properties share a common virtue. Each lets the system assume less. A spent OTP is worthless, so even if someone breaches the booking database, they recover a pile of dead numbers. A standing PIN is a permanent credential, so that same database becomes a store of working secrets for every user. One breach compromises everyone at once, for as long as the PINs remain unchanged. The static model quietly assumes the backend will not be breached, or that a breach is survivable. That is a great deal to ask of four digits that never change.

Detection matters too. Because each one-time code maps to one booking, misuse is visible in principle, and expiry cancels the code automatically. A leaked PIN produces a fraudulent ride indistinguishable from a real one, with no automatic revocation and no natural habit of rotation.

Any case for the substitution has to be measured against these losses. The argument most often made is convenience: a fixed number spares the rider the small effort of noting a new figure before each trip, and if their phone dies, they can still recall it from memory. But on a per-ride system, the code appeared on screen the instant the booking was made. Nothing had to be awaited, and no message chased. The substitution removes only the act of reading a fresh number, which in-app display had already reduced to a glance. The rider still recites a code on every ride. What changes is not the labour but its appearance.

The stronger arguments are engineering ones, and they deserve credit. Generating and delivering a fresh code for every booking is expensive at scale. Message delivery in some parts served by Uber is unreliable. A static code is a coherent answer to those constraints.

The point is not that the PIN is an objectively wrong choice, but that it carries a security cost that the convenience framing hides. The right question, then, is not which code is more convenient but what threat model each design encodes. An OTP limits the damage caused by insider threats, opportunistic data breaches, and leaked credentials. The fixed PIN shifts more trust onto drivers, backend protections, and post-hoc fraud detection than a one-time code does. Neither threat model is obviously wrong, but only one of them is stated out loud. A system’s security rests on knowing which assumptions it is actually making, not the ones it believes it is making.

The lesson is finally one about names. A one-time password earns its name by being used once. A number used indefinitely keeps the name while discarding the property it described. Calling a PIN an OTP blurs an information security boundary, and users tend to believe that the same trust assumptions hold behind the two. Whichever we choose, the choice should follow from an honest account of the threat model: Who the adversaries are, which assumptions we are willing to make about them, and what the cost of getting those assumptions wrong turns out to be.

The writer is assistant professor of Computer Science, Ashoka University (Delhi-NCR). The views expressed are personal and do not reflect those of the university