88

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?

GGMG-he-him
  • 1,045
  • 8
  • 12
  • 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 Nov 05 '16 at 05: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 Nov 05 '16 at 07: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. – Out of Band Nov 05 '16 at 09: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 Nov 05 '16 at 14:00
  • 1
    Most people use crap passwords that someone could easily see and remember, but most people can't memorize a 16 digit number in a short amount of time by sight only. – Weaver Nov 06 '16 at 13:20
  • 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 Nov 06 '16 at 23:19
  • This is a meaningless question. The only possible answer can be 'becaue that's the way they designed it' in each individual case, and it's not impossible that you can find a case where the password field *isn't* blanked out, so there is also a probably false premiss problem. – user207421 Nov 07 '16 at 08:39
  • related http://security.stackexchange.com/questions/127063/is-pin-affective-security-for-credit-cards-considering-its-not-always-needed – Celeritas Nov 07 '16 at 08:41
  • @Jase do you mean *your* computer in a public place? Because if the owner of a public computer wanted that data they'd just install a leylogger, and it wouldn't matter what symbols were displayed. – Chris H Nov 07 '16 at 09:40
  • @paj28 CVV works because it's very short, and while the user is likely to be reading it off the card it's generally small enough print that you'd notice someone reading it. But it probably adds very little security – Chris H Nov 07 '16 at 09:41
  • Entering a password in front of someone else is a common situation. Entering a credit card number or social insurance number is not. Why does the answer have to be complex? –  Nov 08 '16 at 03:51

7 Answers7

57

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.

Out of Band
  • 9,200
  • 1
  • 22
  • 30
  • 8
    Exactly. Blanking fields like these would be a usability nightmare. – Periata Breatta Nov 05 '16 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. – dave_thompson_085 Nov 06 '16 at 07:22
  • 1
    @PeriataBreatta Don't put UX over security as it has been in the past – cat Nov 06 '16 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 Nov 07 '16 at 08:19
  • Bruce Schneier has an interesting take on that which I really like: [Stop Trying to Fix the User](https://www.schneier.com/blog/archives/2016/10/security_design.html) – Out of Band Nov 07 '16 at 08:45
  • 12
    @cat Isn't it true that "security at the expense of usability comes at the expense of security?" – Angew is no longer proud of SO Nov 07 '16 at 09:31
  • At least in my country, a Credit Card Number is not a sensitive information (it is even printed in every receipt when you use the card in the real world). Using the number in an online transaction is usually not enough - you have to confirm a temporary code received by smartphone. So no need to hide it – edc65 Nov 07 '16 at 11:12
  • "many secrets need to be shared too" if this is the case, then they are not secrets. Passwords, CVVs, debit card PINs are secrets, you will never have to share these as they provide authorization to a transaction, only the owner should have access to them. – user1301428 Nov 08 '16 at 12:06
  • 1
    You and I can share a secret we don't tell anyone else (I am actually Batman, and only you, my loyal sidekick, knew this until just now). Some documents are classified "top secret", but that doesn't mean only one person has access to it. User account passwords and PINs just happen to be secrets that don't need to be shared with anybody else, as you correctly point out (although I would have no problem whatsoever to trust my wife with my debit card pin, since we're sharing the same bank account anyway...). – Out of Band Nov 08 '16 at 13:23
  • This is the right answer. Although my credit card number is a sensitive information, it is no secret information. A password is something only I know. Even the website does not know my password. Whereas it knows my credit card. The bank knows my credit card number. So this is no secret at all. – cornelinux Nov 10 '16 at 20:00
29

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.

user1301428
  • 1,947
  • 1
  • 23
  • 29
  • @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? – user1301428 Nov 05 '16 at 10:15
  • 1
    @PascalSchuppli oh right, I see! Gotcha – user1301428 Nov 05 '16 at 10:18
24

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.

John Deters
  • 33,897
  • 3
  • 58
  • 112
  • 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 Nov 05 '16 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). – Periata Breatta Nov 05 '16 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. – Periata Breatta Nov 05 '16 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. – John Deters Nov 05 '16 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. – John Deters Nov 05 '16 at 20:08
  • @PeriataBreatta You should check your statements no matter how secure cards get, as it will never be perfect, and even well-intentioned charges can wrong. I've never had it take more than five minutes to dispute a card and get it taken care of. Even the most minor security features (like blanking out the field and making me type it multiple times) would use more of my time than that. Maybe you should switch banks? – Kat Nov 05 '16 at 21:00
  • @JohnDeters it's no different than a store deciding what to lock in a case or not. If it cost them less to implement more security then they would do that. Security isn't free either, and often costs more than fraud or theft. – Kat Nov 05 '16 at 21:05
  • @Kat It's bad, then bad things could come to you sometime, somewhere. I've heard a story in my country, where this practise isn't common, that someone asked a friend to pay something from another country for him, and the friend later wrongly disputed the payment. His account got banned immediately because the service provider is angry as they received a fine for this dispute (without anyone actually investigating this matter), and they have stated this in their term of service. Technically he should be doing things wrong in your terms, but it's quite unexpected here. – user23013 Nov 06 '16 at 08:19
  • @Kat If it's the bank who eat the loss, then no problem, and it's exactly like the store security example. But the fact is they are forcing merchants to accept that, I suppose. The merchants may not think it saves more but all banks do things like that, and they have to find a way to live. When it doesn't actually saves more, the cost will be reflected to the price of everything you buy. – user23013 Nov 06 '16 at 08:37
  • @Kat Ideally, the merchants could charge less if you use a bank that uses better security and don't accept these disputes, or handle them better. But that is suspicious, inconvenient, difficult to advertise, causing surprise, and having a lot of other hassles all because they are compared to the current "normal" way chosen by the banks, and not for they are really cheaper in ideal state. They might be actually cheaper in ideal state but who knows. That all doesn't matter for banks. – user23013 Nov 06 '16 at 08:41
  • @Kat Even if there isn't such problems, someone should be free to question the banks, and theoretically, potentially allowed to create better banks in their term themselves. If this is supposed to be ridiculus, the market shouldn't be expected to be free enough to be in the optimal state, so you should be paying something more too. – user23013 Nov 06 '16 at 08:42
  • just to extend the part about challenge-response: those devices the banks use in europe got a way to transmit the data via flickering code to avoid keying in those long number chains. – masterX244 Nov 07 '16 at 08:52
3

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.

Jared Smith
  • 1,978
  • 1
  • 11
  • 12
  • 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 Nov 06 '16 at 01: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 Nov 07 '16 at 02:59
  • @newcoder Those are what those things are, tho'. – Williham Totland Nov 07 '16 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 Nov 07 '16 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 Nov 07 '16 at 17:21
  • @Luc so the reason non-passwords aren't masked is because other HTML authors were as confused as @Jared Smith about `type=password`. That's reasonable, but doesn't make this a good answer. If this answer said "Because HTML authors didn't understand `type=password`" then it might be a good answer. – ScottJ Nov 08 '16 at 04:21
  • @Jared Smith your Nov 9 edit shows continued confusion about `type=password`. There's no reason the HTML author couldn't have multiple input boxes to break up the number, all using `type=password`. This answer is still completely wrong. – ScottJ Nov 14 '16 at 23:31
2

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.

Community
  • 1
Wildcard
  • 158
  • 2
  • 9
-1

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.

micheal65536
  • 1,746
  • 1
  • 10
  • 14
-3

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.

user23013
  • 710
  • 5
  • 11
  • 2
    This doesn't look like an answer to the question but a comment on some other answer? – schroeder Nov 06 '16 at 09: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 Nov 06 '16 at 09: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 Nov 06 '16 at 09:36
  • @schroeder Websites don't display passwords on their pages, while they might display other informations. – user23013 Nov 06 '16 at 09:41