4

Not (necessarily) a duplicate of: Should both user ID and Password be masked for online banking?
Definitely not a duplicate of: Should usernames be kept secret?

I can sense your finger on the "mark as duplicate" button so first of all, let me clarify that for masked I do not mean secret. I mean masked only while inserting username and password, and not for the obvious reason you would expect (keeping it secret).

I remember when I was at the college, a professor of ours revealed his password to the entire classroom. His computer was connected to the projector, and he was entering his login data to access a sort of private area containing (rather unimportant) protected information. He entered the username, but then, when he was entering the password, the page unexpectedly refreshed and he ended up writing the password completely unmasked on the username field.

Of course the username was not meant to be secret, as it was just his well-known e-mail address but, you know, he was using that password for... kind of everything, including, of course, that particular restricted area.

Bottom line is: according to me, when users are entering login information, they should be into a "protected zone", in terms of UI, where they can make whatever silly mistake without their password being revealed to people watching. After this incident, I started paying attention to this issue and I found that even I did myself this mistake several times, especially when inserting SSH login data (because maybe the Enter key was just a little bit sloppy), but fortunately no one was watching.

I think the username, for public it might be, should be masked as well, to protect the password.

  • Thanks for the edit in the title but it made the first paragraph quite odd, as the word "masked" is used for the first time. – gd1 Mar 14 '15 at 23:57
1

Theoretically, the professor should have disconnected the computer from the projector during the class. Any number of things can go wrong when typing a password that should be encoded in front of a class of students.

It would give the impression that the username needed to be kept secret and would make users think that the username was highly protected by the application to a similar degree as the password. If your application is such high security that you would already be storing the username in a hashed or otherwise further secured manner, the login page could mask the username as well, but there may be usability problems:

  1. If the username were to be masked, there would be no autocomplete for that field, probably making people annoyed at the extra time required to access their account.
  2. Users may want to try out different usernames to see which one works. If they can't see it and can't see the password, they will have a more difficult time figuring out if they typed the username wrong, the password wrong, or if the username (or email) was not the one used to register in the first place. Users could simply use a text editor beforehand to make sure, but that kind of defeats the purpose.
  3. The chance of typos is greater. Because users can't see the username, their chance of making a typo is greater since they may have made a mistake in either the username or the password field.
  4. Users do not get warned when caps lock is on (unless the application tries to do this). Normally, they may type their username and realize that caps lock is on. Then, they turn it off and restart. Without seeing either field, they would not notice this.
  • He was presenting, and sh*t happens unfortunately. Anyway, I do see your point even though I don't see the fact that users may perceive "that the username needed to be kept secret" as a problem (who cares) whereas the auto-complete argument is totally understandable... but it can be solved in several ways. For example, the field is pre-filled and uneditable, and to change user you have to hit a button "Not foo@bar.com? Login with a different username". – gd1 Mar 14 '15 at 23:45
  • True, but how about which element to use? Would a password input be used or a text one which changes the characters with JavaScript? Then, what if a user does not have JavaScript enabled? – Anonymous Mar 14 '15 at 23:47
  • Well, I am challenging the very existence of a "password" field having different characteristics of the "username" one. This question does not necessarily apply to web pages, with this HTML standard, with the tools we have available now. I am indeed challenging how things are done now, I am not looking for a quick hack that should 'fix' your web pages. Maybe (probably) I am wrong, but I do not care about how HTML handles this now. – gd1 Mar 14 '15 at 23:49
  • Ah, so you're not necessarily asking if that would be good for a particular site. You want to know why a username field was chosen to be shown while a password one is not? – Anonymous Mar 14 '15 at 23:51
  • 'Why' is pretty obvious: it is not secret. I think (not assert) it was a wrong choice, and I explain why. – gd1 Mar 14 '15 at 23:51
1

This a very good question. It is not difficult to imagine people making mistakes when logging into their account in a hurry, ocassionally missing a Tab and ended up typing (or worse submitting) their entire password on the username field.

It is important to understand that the objective for password masking is to prevent shoulder surfing. It doesn't prevent kegloggers from finding out your password; neither does it prevent a MITM from intercepting your password in plain text transmitted over an unencrypted channel. Nevertheless, it is always a good habit to check your environment first before performing an authentication to minimize your exposure to the risk of shoulder surfing. In the rare cases where you have to do an authentication in front of an audience, special care is required.

Having said that, the specific implementation of the login interface is usually a balance between risk and usability. For mobile web applications, there are already some websites that do the exact opposite, i.e. unmasking the password during registration to improve usability.

In the case of your professor logging in to the school system, it may provide a good argument to mask the username field. However, as pointed out by Anonymous, there is a trade off in terms of usability. So, it is really up to the developer of the system to decide whether risk of password disclosure by a few careless individuals is worth making the login interface less usable for everyone.

A better option is to educate all users on basic information security, like not sharing password with other accounts. Because, all the effort that goes to improve security comes to naught if the end user is reckless and writes his password on a post-it note and stick it to the monitor!

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.