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?

  • 50
    My guess would be that its mostly tradition and user expectation, websites only blank out passwords because the users expect the passwords to be blank since thats how it's always been, but that's a damn interesting question
    – trallgorm
    Commented Nov 5, 2016 at 5:19
  • 21
    Credit card info are not meant to be secret, otherwise how you would make a purchase without communicating your card details. Password, in another hand is meant to be kept undisclosed, it is the only info that allows you to authenticate against your online service.
    – elsadek
    Commented Nov 5, 2016 at 7:08
  • 5
    @trallgorm: completely agree. Note: Password blanking has been receiving negative press from various sides (interface people and infosec) for a while, if I remember correctly, that's mostly because it makes entry of long and therefore more secure passwords harder. Some sites now provide a button to unblank the password for this reason. Commented Nov 5, 2016 at 9:50
  • 7
    Some sites do blank fields other than passwords. Your credit card security code (CVV2) being the most common. This is the exception rather than the rule.
    – paj28
    Commented Nov 5, 2016 at 14:00
  • 5
    Just an aside on this "shoulder surfing" thing. If I put my phone into video record and it records you logging into your computer, I can frame-by-frame figure out your keystrokes with a very high degree of accuracy. So blank password fields only keep out very casual threats.
    – Zan Lynx
    Commented Nov 6, 2016 at 23:19

7 Answers 7


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.

  • 8
    Exactly. Blanking fields like these would be a usability nightmare. Commented Nov 5, 2016 at 19:21
  • 4
    Credit card numbers (actually payment cards, which also includes most debit and gift) have 'Luhn' checksum, plus in most tranactions they are sent within minutes to the issuer, with name and CVV2 and/or address (AVS) and checked. (US) SSN does not have any redundancy, and in some common situations like a bank deposit or benefit claim it may not be checked for days or weeks -- or not at all because of restrictions on who can use the verification services. Both SSA and IRS need whole systems to fix 'inaccurate' SSNs -- although that includes both mistakes and intentional frauds. Commented Nov 6, 2016 at 7:22
  • 1
    @PeriataBreatta Don't put UX over security as it has been in the past
    – cat
    Commented Nov 6, 2016 at 16:02
  • 5
    @cat Conversely, making UX more difficult than it has to be in the name of security is not a spectacularly good idea either, since it leads to users actively bypassing security in order to achieve the functionality they desire. There has to be a balance.
    – Iker
    Commented Nov 7, 2016 at 8:19
  • 12
    @cat Isn't it true that "security at the expense of usability comes at the expense of security?" Commented Nov 7, 2016 at 9:31

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.

  • @PascalSchuppli true, they shouldn't. This reminds me of the debate about encrypting the whole database vs just the sensitive columns. But then, anything could become too sensitive: I personally consider my family name more sensitive than my CC number, which I can change quickly anyway, should we mask names and surnames too? Commented Nov 5, 2016 at 10:15
  • 1
    @PascalSchuppli oh right, I see! Gotcha Commented Nov 5, 2016 at 10:18

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.

  • 2
    I've never understood the outage over credit card companies leaving their cards so insecure. You aren't liable for fraudulent purchases. It's the bank's money, not yours. Why do you care at all if they protect it or not? Maximizing their profits and minimizing hassle for customers is the best outcome for both parties.
    – Kat
    Commented Nov 5, 2016 at 17:05
  • "So for now, web transactions are still insecurely relying on static CVV numbers" ... or 3D Secure, which allows the card issuer to perform whatever authentication step they want (but typically ends up being entering a password that isn't sent to the merchant). Commented Nov 5, 2016 at 19:17
  • 2
    @Kat -- if fraudulent transactions were magically automatically detected and returned to you without requiring intervention, I'd agree with you, but in reality the result is you have to periodically check your statements for unauthorized transactions and then complain (usually repeatedly) to the bank until they agree to a refund. It can take hours of your time, for which you will not be compensated. Commented Nov 5, 2016 at 19:19
  • 5
    @Kat , I don't consider enabling fraud to be OK, because those costs ultimately come out of my pocket in terms of higher prices. Commented Nov 5, 2016 at 19:48
  • @PeriataBreatta, sure, there are a whole family of problems that challenge/response alone doesn't solve (fraudulent merchants involved in capture/playback, social engineering, etc.,) and there are hundreds of one-off custom solutions for specific situations. But those just fracture the market and muddy the waters further. A trustworthy standard needs to emerge but nothing has come close. Until then, we're all having to tackle the problem individually, with sub-par or password-only tools like Yubikey, Mooltipass, PasswordSafe, OAuth, SMS, Google Authenticator, etc., etc., etc. Commented Nov 5, 2016 at 20:08

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.

  • 7
    The only difference between type=text and type=password is whether the field is masked. The HTML author could use type=password on a CC or SSN field if they chose to. There's no technical reason why they couldn't mask those fields. This answer is completely wrong.
    – ScottJ
    Commented Nov 6, 2016 at 1:23
  • @ScottJ I once had Chrome offer to save my payment card number as a "username" and the CVV as its "password" because that's the impression it got from the form. Very disconcerting.
    – newcoder
    Commented Nov 7, 2016 at 2:59
  • @newcoder Those are what those things are, tho'. Commented Nov 7, 2016 at 10:31
  • 2
    @ScottJ Yet type=masked would be much more inviting to use for non-password fields than type=password. It's clearly not the true reason why only passwords are masked, but the answer makes a good point that almost certainly contributed to it.
    – Luc
    Commented Nov 7, 2016 at 15:13
  • nowadays lot of dev frameworks offer for FREE custom widgets that format specific information like phone number, postcode; and so for sensitive information like card number. The implementation is well established on both client and server side. I mean there isn't too much work to put, in a web form, distinguishable SSN type field.
    – elsadek
    Commented Nov 7, 2016 at 17:21

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.


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.


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.

  • 2
    This doesn't look like an answer to the question but a comment on some other answer?
    – schroeder
    Commented Nov 6, 2016 at 9:04
  • @schroeder Er, on which answer? It's impractical to get rid of everyone around you when you input the password. It's somewhat practical for inputing / viewing other informations. So they are treated differently, as the question asked?
    – user23013
    Commented Nov 6, 2016 at 9:08
  • 3
    Why are you talking about password storage? Most of the relevant bits to this answer are already covered by other answers. I'm having trouble seeing how this answer relates to the question and how it differs from other answers. I think you might need to connect some dots.
    – schroeder
    Commented Nov 6, 2016 at 9:36
  • @schroeder Websites don't display passwords on their pages, while they might display other informations.
    – user23013
    Commented Nov 6, 2016 at 9:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .