Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
8  
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 yesterday
5  
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 yesterday
    
@elsadek "it is the only info that allows you to authenticate against your online service" It's not the only info, it's the traditional info. There are other authentication mechanisms, passwords just happen to be the most used one. – user1301428 yesterday
1  
@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. – Pascal Schuppli 23 hours ago
1  
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 19 hours ago
up vote 13 down vote accepted

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.

share|improve this answer
1  
Exactly. Blanking fields like these would be a usability nightmare. – Periata Breatta 13 hours ago
    
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 1 hour ago

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.

share|improve this answer
    
No bystander looking over your shoulder should need your cc or social security number either, so this isn't a very good reason not to blank these fields on web forms... – Pascal Schuppli 22 hours ago
    
@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 22 hours ago
    
No, I'm not advocating masking more fields, just pointing out that the intended audience of the cc number isn't the guy right behind you, so your argument is somewhat weak there :-) – Pascal Schuppli 22 hours ago
    
@PascalSchuppli oh right, I see! Gotcha – user1301428 22 hours ago

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.

share|improve this answer
    
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 16 hours ago
    
"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 13 hours ago
    
@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 13 hours ago
    
@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 13 hours ago
    
@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 13 hours ago

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 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.

share|improve this answer
1  
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 7 hours ago

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.

share|improve this answer

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. For other informations, people are very likely to input them in secure locations without anyone around. And when you click that option using these informations, you 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.

share|improve this answer
    
This doesn't look like an answer to the question but a comment on some other answer? – schroeder 4 mins ago

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.