Why don't we use HTML password inputfields for usernames and 2FA codes in the front-end of web applications?

Question

When entering a username and password on a web application I have always wondered why the username often equals personal email address (which is often known or easy to guess or find). A random username for login would be more secure in my opinion.

However, I also wonder why often we show the username field in plain text and don't protect it the same against shoulder surfing, screen grabbing et cetera, by hiding what the user types using a HTML password input field instead of text input field. The very same thing really applies on 2FA codes that are usually being typed into a visible text field.

Why don't we use HTML password input fields for usernames and 2FA codes in the front-end of web applications? Why is this not a common practice? Even with a 'preview eye' button next to it, it's likely safer than just showing it in plain text.

Also are there any described best practices that recommend web developers to not use an email address as username, and hide the username and 2FA codes in the front-end too?

Answer 1

When using password authentication, then the authentication element is in fact the password. The username is just an identifier which could be entirely public (unless it contains sensitive data like an e-mail address, of course). Using a random username as an additional secret makes little sense, because this forces the user to effectively manage two secrets while providing no benefit over a single strong password. There are also practical issues. Do you store the username as plaintext on the server? Then it's hardly a secret. Do you store a simple hash? Then the username will have to be very long or very complex to withstand brute-force attacks. Do you use a specialized password hash algorithm like Argon2? Then you'll need yet another identifier to look up the hash parameters. None of this is really good solution. In general, the username should be chosen by the user and be simple enough that they'll easily remember it.

The reason why 2FA codes are shown without masking is because they're only valid for a short amount of time (e.g., 30 seconds) and only work in conjunction with the password. So even if somebody sees the code, this doesn't immediately give them access to the account. It's also a matter of usability. Having to type in the code in a relatively short amount of time already creates some stress. If the user cannot even see the code and makes a mistake somewhere, this will quickly become frustrating.

If you want to increase security, then tell your users to generate strong random passwords with a password manager. Or look into passwordless alternatives like WebAuthn with passkeys.

Answer 2

Usernames are intended to identify the individual user, and they're not usually considered to be secret. And this is especially true when you're threat is someone shoulder surfing, because they're standing right next to you. So you could hide the username from them on the login screen - but then then what? If they're looking over your shoulder they can probably see your username/email/whatever once you've logged in, as well as everything else that you're doing.

So you gain very little benefit from hiding it on one screen, and the penalty you get is that users are more likely to run into issues trying to login because they can't see what they're typing - which leads to more locked out accounts, more support tickets, and more frustrated users. So most people have decided that its not worth the effort for the very marginal benefits it brings.

---

As for OTPs, there's more of an argument that they should be hidden, and I've definitely seen some sites that do hide them. But the fact that they have such a short lifetime (and in many cases can only be used once) means that many sites don't bother doing so. It's hard enough persuading people to setup and use MFA in the first place, so adding additional layers of difficulty may end up being counterproductive.

It may also be that they've found people are more likely to make mistakes typing them than they are with passwords (as its a new code every time, and they're having to do it quickly) - but that's just speculation on my part.

Answer 3

Adding to what was already said:

• A lot of people use smartphones for internet access. Typing on a virtual keyboard makes easier to make mistakes, and having to type again a random username plus a password plus an OTP without knowing for sure which one you mistyped is frustrating. Having to click on the "eye icon" on the field on a small smartphone screen will not always be easy for all the population.

• Usernames are not expected to be secret. It just becomes a second password, and the user will end up using his email anyway because it's easier to remember.

• I personally dislike OTP being masked. If I mistyped it, I usually have to wait for the next token to be generated, and I spend that time complaining about the developer, the service and all. It's ephemeral, so knowing only it won't facilitate an account takeover.

• Acording to AviD's Rule of Usability:

"Security at the expense of usability, comes at the expense of security."

If the login screen is too complex, users will try to find a shortcut that will reduce the security, like using the same password for everything, having the username the same as the email, or disabling OTP. Or give up and use another service.

Answer 4

We don't use password input fields for usernames because it prevents the user from correcting mistakes. This could be simple spelling mistakes but in the modern era we need to consider Apps themselves, browsers and plugins will often automate or pre-fill the username field, sometimes this is from the previous visit, other times it is simply the email address stored in the browser or plugin profile. Users with multiple identities or on devices that are used by multiple people could easily have the wrong username filled in.

Making the username field clear text reduces round trips to authenticate simply because the username was incorrect, in turn reduces user frustration in your site.

It is a bad practise to use password input fields for 2FA codes for similar reasons to above, except that at the 2FA prompt most implementations will activate stricter lockout policies if the 2FA value is incorrect a small number of times, the value itself should be single or limited time use, so the risk is lower if someone does see it, as they would have to see it, and use it before the first user. A worse issue is that some auto-filler plugin logic is very aggressive and they can treat any password input fields as passwords, and might auto-fill the password for a site into the 2FA field that was implemented as a password input, this would usually be wrong because MFA/OTP codes are usually generated for the specific session request and the pre-filling logic may not have access to this.

Answer 5

I agree only 80% with the other answers here that cleanly conclude that usernames are non-secrets. That is true if the username is completely "independent" of the secret password. In other words, the username shouldn't provide any clues about the password's content, and it shouldn't provide an avenue for retrieving or bypassing the secret password.

The reality is that the username is often an email -- the same email used for password resets -- which breaks the assumption of independence. There's an entirely different class of attacks available to someone with that information.

Now, is this a big deal? Probably not enough to warrant hiding the username field. But it's enough that you should double-check assumptions about non-secrets in your app to make sure that's actually what they are