Why are password boxes always blanked out when other sensitive data isn't?

Question

So far as I know, password boxes and PINs are always obscured in some way in order to prevent people from looking over your shoulder when you enter it. However, other important information that I type into a web form (credit card number, social security number, etc.) that I would also like to protect from rubbernecking is hardly ever obscured.

As a concrete example typing your login password into Steam or Amazon is properly blanked out but typing in your credit card number when making a purchase is revealed as plaintext. Intuitively, it feels like you would want to blank anything that could be stolen, credit card info included.

Is there any particular reason why only passwords and no other sensitive data is usually obscured?

Answer 1

I don't think this is about secret vs sensitive information, eg "secret information is masked and sensitive isn't." (the distinction is problematic; many secrets need to be shared too).

I think cc and ssn information isn't blanked for several reasons. They're not hard fact, but still, here are a few:

1. Doing what everybody else is doing, not surprising the user. Passwords came long before web forms and were already masked. So when they were used in login forms, they were masked too. When online business and administration came along, prior art (paper forms) required unmasked entry of sensitive information (obviously), so web forms made the same choice.

2. It would be very easy to make a mistake and enter a wrong number if you didn't see what you typed. In the case of a wrong password, this is only mildly annoying and you get instant feedback; in the case of other wrong sensitive data, this might have further consequences which isn't immediately clear (such as a request to a government office being denied because of a wrong SSN or a payment not going through - although in the cc and ssn cases, this is usually hedged against by looking if the checksum is right and providing immediate feedback if it wasn't)

3. Many people don't know their cc number from memory and copy it down from the actual credit card. So the number is there to be seen by a bystander anyway; blanking the entry field wouldn't help much to protect the number at the client end and thus doesn't merit the additional difficulties caused by 2.

4. Impact - A stolen cc number doesn't necessarily have the same impact as a stolen password, especially if you consider that information stolen by looking over your shoulder would most likely be stolen by people who know you (collegues at work, family members, classmates etc) and want your password for a very specific reason that would have personal consequences. OTOH, even if they were interested in your cc number, you wouldn't have to take the financial damage because the cc company would probably cover it. For the same reason, you don't mind letting a waiter or store clerk see your credit card, even though he could copy it and sell it to someone else...

Number 4 may not apply to other kinds of sensitive information, though.

Answer 2

This is because we are dealing with two types of information here: sensitive information vs secret information.

• Sensitive information is data that has some significance from a security/privacy perspective, and which could definitely cause some issues if fallen into the wrong hands. However, data such as your SSN, credit card number, photograph etc. is not secret: a third party will need access to it, whether to process an order you placed or to confirm your identity.

• Secret information, on the other hand, is information that noone will ever need to have access to, for any reason. Nobody should need your password to do anything, therefore this field is usually masked.

Ideally, you would want everything to be masked, but there are usability issues to consider if you do it. At the end of the day, you will always have to compromise, and using these two categories as a filter is just one common way to it.

Answer 3

There are a lot of ongoing problems in data security. This is one of them.

TL;DR: Blame the credit card industry.

The root cause is the mistaken concept that by giving your identity you are also granting your authorization. This was the horrible basis that credit cards were built upon, and is why the situation is as bad as it is today.

Your identity (credit card number, SSN, etc.) shouldn't ever need to be kept secret, because who you are is not a secret. You can't stay secret from an online merchant, because they have to ship you the stuff you buy. You can't stay secret from any merchant with a credit card because the merchant wants your bank to give them money. You can never manage to stay secret from the tax man. And you don't want to stay secret from your health provider, who needs your medical history to treat your problems.

When credit was invented, this was not a big problem. People knew each other, and both sides trusted each other in the transaction. But the system was so incredibly easy to abuse that fraud snowballed out of control.

Credit card transactions are extremely profitable. Desperate to keep people from being afraid to use their insecure credit cards, the Payment Card Industry (PCI) successfully shifted the blame to the merchants, saying "they're not keeping your credit card numbers safe", while handwaving away the fact that the entire system was built on a flawed premise of trust. (I allocate all blame to the credit card industry for perpetuating this security mess in order to preserve their profits.)

The solution is to separate your identity from your authorization. People don't have to be afraid of leaking their identity if the identity is worthless without authorization.

But how do you grant authorization when there's the possibility of an untrusted middleman? There's a bad way and a good way. The bad way is the password. By proving you know a secret, you can authorize the use of your identity. But plain passwords are as problematic as plain credit card numbers are today. If you tell your secret to the merchant who then passes it along to the bank, a man-in-the-middle anywhere along that chain can copy your secret and forge your authorization.

The only good way to securely give your authorization is to use challenge-response. This solves the entire problem, except we humans can't do effective challenge-response in our heads. This has been brilliantly overcome by the introduction of chip cards and the EMV protocols. The card does all the hard work of accepting the challenge and generating the response. For added security, the card can be designed to not generate a valid response without a PIN.

In this rose-tinted world, not only do you no longer need to protect the credit card numbers, you don't need to protect the response because it's unique to the challenge.

We may get there, someday. But right now, EMV is still not perfect. Because it can use only the little gold contacts to communicate (or sometimes RF), and phones and computers don't have the universal ability to talk to chip cards, there's no good way to use EMV to authorize a transaction on a web browser or over a phone. (There are pocket chip readers in use by some European banks, but these are awkward devices that require the user to perform the extra steps of typing in a bunch of digits as the challenge and entering their response.) So for now, web transactions are still insecurely relying on static CVV numbers, which are the equivalent of passwords.

And that doesn't solve any non-credit problems, either. Access to medical records, web sites, and everything else that needs authorization has the same problem, and needs a good solution. There are many halfway solutions like OAuth, but as Yahoo!'s breach demonstrated, they're not good solutions. And whatever solutions come out, they will be fought in standards committees by companies all clamoring for a profitable piece of the pie; competing governments who want to control and gain backdoor access; technical firms who want to build the infrastructure, etc. It's a foregone conclusion that the compromises will not be both secure and interoperable.

Once those problems are sorted out, and similar solutions are applied to health care, web site identity, etc., we may see the end of the masked password box. I give it at least 50 years before we get there, if ever.

Answer 4

Although User1301428's answer does a great job explaining the difference between passwords and other types of sensitive data, there's also a technical reason: HTML input tags (and whatever the equivalent in the other platforms).

Since Internet Explorer 2 (back in 1995, and by extension the first release of every other browser) the humble input tag has supported type="password", which on pretty much every browser will mask the text. Everything that recreates the behavior of that tag from scratch because reasons will typically also mime that behavior.

But there's no "credit card" or "ssn" type. So while the developer gets it for free as part of the web (or other) platform, they'd have to use the password type for them (violating the now common expectation of having multiple input boxes to break up the number) or implement it by hand for other data. Then there's the whole business of correctly typing a 9-16 digit number when you can't see the digits and... yeah.

Answer 5

There are two immediate reasons/differences I see. The first is mentioned in passing in the excellent accepted answer, but I haven't seen the second point mentioned here.

1. A wrong password will be immediately noticed and rejected.

   Unlike a credit card number or SSN being entered incorrectly with potential consequences, a login form filled out with an incorrect password will give immediate feedback, often with no other consequence than being required to input the password again.

   Of course, this is annoying of itself; hence some websites now offer a "show password" option as a usability improvement.

   Still, compared to finding out several minutes or hours later that your purchase was unsuccessful (due to error in entering credit card info because the credit card field was blanked out), or finding out months later that your tax filing was rejected because your SSN was entered incorrectly (because the field was blanked out), a login failure is a pretty tame consequence.

2. When setting a password users expect to be prompted to enter it twice.

   This is the mitigating factor on blanking out the password field: You get to enter the password twice, to be sure you entered it correctly. (Of course this only applies to setting the password in the first place, when there is nothing to compare the entered value to so you can't have a "wrong password" rejected.)

   Imagine if the credit card field were blanked out. Would you like to enter your credit card information twice, both times doing it blind? (I wouldn't.) This would be an improvement over entering credit card information blind only once, but it would be quite a step down from entering the information and checking that you've entered it correctly—as you can do today.

Answer 6

It's just common practice. There are many times when I would far rather have a password visible. Similarly, users are going to get confused if they can't see their card number as they type it in. There's no other reason.

Note that some websites/web browsers these days allow one to "unmask" a password field if the user would prefer to see their password and is comfortable that no one is looking over their shoulder.

Answer 7

In a well-designed system, passwords shouldn't be stored in plain text on the server. The only situation that you may see the password is when you input it. And you might do that everywhere when you want to access your account. That is, in every situation that the user might be able to see their passwords, one should assume there might be other people around.

For other informations, people are very likely to input, or read them in secure locations without anyone around. In many cases the user just input those informations once and use the website for a long time. And when the user click that option using these informations, they should be already prepared.

TL;DR: It's impractical to get rid of everyone around you when you input the password.

I'm not saying they shouldn't be blanked out. But this might not be their highest concern, depending on situations.