51

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?

Peter Mortensen
  • 877
  • 5
  • 10
Robin Salih
  • 572
  • 4
  • 8
  • 7
    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 '19 at 20:44
  • 1
    Can you give example for sites? Facebook, Github, Azure, AWS, Google all show the digits. – eckes Sep 28 '19 at 08: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). https://imgur.com/a/RNMr555 – Aloha Sep 29 '19 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 '19 at 12:34
  • 1
    @eckes I've seen it in a few places including Natwest Online banking. – Robin Salih Sep 30 '19 at 16:51

5 Answers5

65

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.

  • Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/99174/discussion-on-answer-by-mechmk1-why-do-many-websites-hide-input-when-entering-a). – Rory Alsop Sep 27 '19 at 14:01
  • 7
    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 '19 at 16:04
  • 18
    @ChristopherSchultz If it's implemented according to the [RFC](https://tools.ietf.org/html/rfc6238#section-5.2) 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 '19 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 '19 at 01: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 '19 at 13:57
  • @ChristopherSchultz admittedly a lot of the solutions were developed before the blockchain hype - Paxos for example is quite old. But consensus algorithms got renewed interest lately with blockchain – slebetman Sep 28 '19 at 14:00
  • @AndrolGenhald "validation has been issued for the first" - shoulder surfer still have time to type it before real user does. I.e. BEFORE "validation has been issued for the first". – Oleg V. Volkov Sep 28 '19 at 18:13
  • 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 '19 at 18:29
  • @slebetman This is a problem with a 30-second duration (for default TOTP parameters). Blockchain is perhaps the worst possible implementation of a countermeasure for this possible attack vector (for for almost anything for that matter). – Christopher Schultz Sep 30 '19 at 15:29
  • @ChristopherSchultz I'm not talking about blockchain. I'm talking about consensus algorithms which predates blockchain but perhaps was not well known enough until blockchain brought them to the forefront. Paxos for example was published in 1988 but software such as Elasticsearch (published 2010) still had/has issues with asynchronous synchronization even though it is a solved problem because its developers wasn't aware that such algorithms exist but there in fact exists a whole family of algorithms. Blockchains wouldn't be possible without consensus algorithms – slebetman Sep 30 '19 at 18:43
30

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.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
  • 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. –  Sep 26 '19 at 16:50
  • 19
    Using `autocomplete="one-time-code"` omits the OTP from the history without being user-hostile. – chrylis -cautiouslyoptimistic- Sep 27 '19 at 01: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 '19 at 07:24
  • They may not have to of course. I just thought it worth mentioning in case someone reckoned "by the time they can see it, it is too late to do anything with" – Josiah Sep 27 '19 at 07:27
  • 1
    A server that doesn't protect against replayed OTPs is pretty much broken by definition... – ilkkachu Sep 27 '19 at 13:16
  • @ilkkachu No, not necessarily. Many “OTP” systems are time-based and have multiple authentication points, creating a window of time during which an OTP not only _can_ be accepted multiple times, but _should_ be accepted multiple times (because the user is logging in to different authentication points within the same short window of time). – Gilles 'SO- stop being evil' Sep 27 '19 at 13:23
  • 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 '19 at 13:36
  • @ilkkachu Not really. The main point of authentication methods commonly called “OTP” today is to be a what-you-have authentication factor: they're a proof of physical access to some device (generally your mobile phone or your SIM). The risk that they protect against is that the what-you-know factor has been leaked. Undoubtedly it would be better if the time-based ones weren't called “OTP”, but the name remains popular even though it's inaccurate. – Gilles 'SO- stop being evil' Sep 27 '19 at 16:50
  • 1
    @Gilles, I think that's the point ilkkachu was making. They're seen as a what-you-have factor, but if they're vulnerable to sniffing and replays they don't prove what you have. – Josiah Sep 27 '19 at 23:04
  • @Josiah No, that doesn't follow. Passwords are also vulnerable to sniffing and replays, but they do prove what you know. OTP tokens are vulnerable to thefts, but they do prove what you have. – Gilles 'SO- stop being evil' Sep 28 '19 at 05:56
  • @Josiah, well, to be honest, if you can attack in real-time, you can still sniff an OTP, you just need to use it before it gets to the server. You don't even need to jam the network if you're just faster than the user. Of course, if the OTP is valid even after it hits the server, it makes it a lot easier since there's no race and the user doesn't get a login error. – ilkkachu Sep 28 '19 at 10:33
  • 1
    @Gilles, frankly, I still don't get why one would implement a time-based OTP and not invalidate the current OTP when used. If you have multiple authentication points, they're either part of the same system, and you could just have one authentication grant access to all of them (repeating the same code three times in three different places doesn't seem any more useful than just entering it once). – ilkkachu Sep 28 '19 at 10:41
  • ... Or the systems are independent, in which case they can only invalidate the used OTP for themselves, and logging in with the same code works. That's just a bit like using the same password in multiple systems, except it's the OTP this time. Then we can argue if that's a problem or not, but thinking about something like TOTP, there's a shared key that generates the OTPs, and if that leaks from one of the systems, then it compromises the others too, just like if a password somehow gets leaked from the password database... – ilkkachu Sep 28 '19 at 10:44
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.

Josiah
  • 1,818
  • 9
  • 14
  • 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 '19 at 09: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.

Hightown Hill
  • 1
  • 1
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.

cornelinux
  • 1,993
  • 8
  • 11