47

I've noticed that on many sites, when they ask for a one-time password (OTP) (usually sent by SMS), the input is hidden in the same way as a password field is.

My understanding is that once an OTP is used, then it is no longer useful for anything.

Is there a valid reason for hiding the input for these fields?

  • 6
    When Facebook started to accept mis-capitalized passwords, some people expressed concerns on whether that was secure. If a site stops hiding input in a field named "password", the same controversy will ensue. – Dmitry Grigoryev Sep 27 at 20:44
  • 1
    Can you give example for sites? Facebook, Github, Azure, AWS, Google all show the digits. – eckes Sep 28 at 8:46
  • 2
    @eckes My bank's 3D Secure thing does it. Whenever I use my debit card, I get taken to that page (*.arcot.com). imgur.com/a/RNMr555 – PNDA Sep 29 at 10:57
  • 1
    In a big form having lots of fields including the password field, a third party may see the password and submit it before the user does. – frogatto Sep 29 at 12:34
  • 1
    @eckes I've seen it in a few places including Natwest Online banking. – Robin Salih Sep 30 at 16:51
64

I'm basing my answer on the assumption that a One-Time Password is used as a second factor, in addition to a traditional username/password combination. If this is not the case, and the One-Time Password is the only factor, then Gilles' Answer is certainly more applicable.


Most likely due to Cargo Cult Programming, which means blindly following patterns that have been observed elsewhere, without understanding the real meaning behind them.

A developer may see the "password" in "One-time password" and happily make it <input type="password">. Afterall, that's what it's there for, right?

Is there a disadvantage?

Security-wise, no. Disclosing a one-time password to a third party (e.g. through shoulder surfing) is not as problematic, because the password loses validity after one use, or after a certain amount of time.

The only imaginable downside would be a lesser user experience, as a user might have trouble ensuring that what they have typed actually matches the password they received.

  • 6
    Depending upon the scheme, OTPs aren't just one-time. For example, TOTP tokens are valid for 30 seconds, regardless of the number of times you actually use the token. In that case, shoulder-surfing can be a problem if the first factor (e.g. password) has already been compromised. – Christopher Schultz Sep 27 at 16:04
  • 18
    @ChristopherSchultz If it's implemented according to the RFC TOTP is one time: "The verifier MUST NOT accept the second attempt of the OTP after the successful validation has been issued for the first OTP". – AndrolGenhald Sep 27 at 21:46
  • 4
    @AndrolGenhald Interesting. Apparently, I had missed that detail when implementing TOTP as an example at some point. This RFC-MUST-NOT requirement makes it difficult to fully-implement the spec in distributed systems. I wonder how many implementations are actually compliant. – Christopher Schultz Sep 28 at 1:41
  • 1
    @ChristopherSchultz - difficult but not impossible. One of the things the blockchain hype taught is that it's possible to develop robust consensus algorithms - something people used to have a hard time with (specifically dealing with the split brain problem) – slebetman Sep 28 at 13:57
  • 1
    @OlegV.Volkov Since we're talking about the entry on the website, the shoulder surfer obviously cannot enter the full code before the real user (although they could potentially submit the form before the real user). If you're talking about shoulder surfing the code displayed on the OTP device, that's irrelevant to the question. – AndrolGenhald Sep 28 at 18:29
31

The reason to hide passwords is to prevent shoulder surfing: someone being physically present (or someone observing through a camera) might be able to read the password on the screen. This is also a risk for a one-time password, but to a much lesser extent for two reasons: the one-time password is only valid for a short time, and it's displayed on the OTP device anyway. But it's a risk nonetheless. Depending on the type of OTP, it may remain valid for a couple of minutes (if it's time-based and the server doesn't protect against replay) or until the legitimate user has finished typing it (if it's sequence-based or the server protects against replay). Often the screen of the OTP device is less visible to shoulder surfers than the computer where the user enters the OTP.

Declaring a field as a password does other things than hiding the data: it may prevent copying to the clipboard, and may cause the application not to record the OTP in a form entry history. None of those has any security benefit, but omitting the OTP from the entry history has a usability benefit: it avoids giving users the impression that the OTP is a valid input later.

These are pretty weak reasons. The main reason is that form designers see that the input is a password of some kind and therefore declare it as a password.

  • 1
    Assuming that a one-time password is used as a second factor, I would consider it much less of a risk, since someone would need to be in posession of the primary factor as well. But this is a good point, I'll add that to my answer accordingly. – MechMK1 Sep 26 at 16:50
  • 19
    Using autocomplete="one-time-code" omits the OTP from the history without being user-hostile. – chrylis -on strike- Sep 27 at 1:21
  • 11
    This may seem like a bit of a James Bond level of paranoia, but one consideration for shoulder surfing security is the network reliability. We push people onto https to prevent automated mitm attacks, but no cryptography ensures the network doesn't go down. An attacker may be able to see the code, jam the signal (e.g unplug the router) and get a good two minutes in the confusion to put it in for themselves. – Josiah Sep 27 at 7:24
  • 1
    A server that doesn't protect against replayed OTPs is pretty much broken by definition... – ilkkachu Sep 27 at 13:16
  • 1
    @Gilles, I don't doubt that they exist, but that really seems to violate the "one-time" property that's right there in what OTP is short for... I always thought that the idea was that once a one-time password was used, it must be assumed leaked, and hence must not be accepted again. Which may mean you'd need a centralized system to keep track of the used OTP, and should have some single-sign on system to authenticate into multiple systems at the same time, but that's what you get. Reaccepting the same OTP just sounds like inviting an eavesdropper to login after you... – ilkkachu Sep 27 at 13:36
16

Speculating about the motive of other developers is perhaps a poor use of time, but I can see one advantage that hasn't been mentioned.

Psychologically, making it look like a password helps people associate it with security. It transfers the message we have pushed for decades that "you don't tell people your password" to OTPs, and hopefully helps a few more users pause and question when Bob Hackerman phones them up asking them to confirm the six digit code he just sent them. The user is usually the weakest part of the system, so that seems like a reasonable place to invest.

Technically, there are disadvantages (like the browser storing it) and it would be better with a dedicated HTML field for OTPs. Even if we had one, it would be entirely reasonable to have it dotted out as the default UX.

  • 2
    I like this reasoning. I know what they are, and about the usual security problems. Joe Blogg's granny on the other hand. Anything that helps the less security literate be more secure is a good thing. – Baldrickk Sep 27 at 9:48
0

The reason for hiding the input of the field maybe due to programming patterns (like @MechMK1 stated), because the developer wouldn't code a separate field for each authentication type offered so they reuse the field with type password. Not doing so could lead to code bloat.

0

An attacker could use the one time password when he sees you typing it in.

It comes down to the question of timing. If he is a sophisticated attacker he might read the not hidden one time password and at the same time block your network connection before you hit enter. So he can read the OTP you are typing, hinder you from sending the form and use the OTP to login as you.

This might sound very awkward, but in our opinion a sincere OTP implementation should take care of this. As @MechMK1 pointed out the OTP is - as the name suggests - only valid once. But the OTP is only invalidated when the server verifies it. And as mentioned, if the attacker can prevent you from sending the OTP to the server the otp is not invalidated and the attacker can use this very OTP before you.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.