Masking Sensitive Information in Category 8

[ImanSharaf]

Currently, ASVS item 2.1.12 (under Category 2: Authentication) states: "Verify that the user can choose to either temporarily view the entire masked password, or temporarily view the last typed character of the password on platforms that do not have this as built-in functionality." This is a valuable guideline for password visibility and user interaction. However, in Category 8, which focuses on Data Protection, there is no similar guideline for the masking of other sensitive personal information, such as credit card numbers, social insurance numbers, ...

I propose the addition of a guideline in Category 8 that requires applications to mask sensitive information, with options for users to view this data securely when necessary. This would align with best practices for data protection and privacy, ensuring that sensitive data is not exposed inadvertently in user interfaces.

[elarlang]

Is the proposed solution is in use in practice?

In the described scenario, sensitive data is already delivered to the client and then you just show it after some separate user action? Maybe instead you only ask it from the server when you need it, show on the screen for the time user needs it and then close this out?

[ImanSharaf]

Masking credit card numbers (and other sensitive information) in applications also helps protect against "shoulder surfing." Shoulder surfing refers to the practice of someone surreptitiously observing or glancing over another person's shoulder to gain information.

[elarlang]

Have you ever seen it used in practice?

[ImanSharaf]

Yes, for our banking and finance related customers, we always recommend that. Also, I have seen that in many websites that process credit cards, (I redacted the last 4 digits)

[elarlang]

I propose the addition of a guideline in Category 8 that requires applications to mask sensitive information

I would limit it to "entering sensitive information". Otherwise it rises the question like I asked here: https://github.com/OWASP/ASVS/issues/1789#issuecomment-1812095858

[tghosth]

I think there are two questions:

• Masking sensitive data on entry
• Not returning sensitive data in it's complete form from the server

@ImanSharaf do you think that requirements for either of those problems exist in ASVS today ?

[elarlang]

@ImanSharaf do you think that requirements for either of those problems exist in ASVS today ?

I can answer myself that we don't cover those things at the moment.

Before jumping to recommendations or for possible requirements:

• do we have any other examples other than payment card number and password, which we should mask when entered?
• do we have any examples, what kind of sensitive data can be entered (let's not take password here, as it is covered by other requirements) to the application, but can not be displayed back to the output?

If we can find examples and it is reasonable, then it should be heavily related with 1.8.1:

#	Description	L1	L2	L3	CWE
1.8.1	[MODIFIED, MERGED FROM 8.3.4, LEVEL L2 > L1] Verify that all sensitive data created and processed by the application has been identified and classified into protection levels, and ensure that a policy is in place on how to deal with sensitive data.	✓	✓	✓	213
1.8.2	[MODIFIED] Verify that all protection levels have an associated set of protection requirements and that these are applied in the architecture. This should include (but not be limited to) requirements related to encryption, integrity verification, retention, privacy and privacy-enhancing technologies to be used, and other confidentiality requirements.		✓	✓

At the moment we describe here potential protection levels.

[ImanSharaf]

@tghosth my main goal here is to mask sensitive information such as SIN and credit card numbers on the user interface side to avoid shoulder surfing attacks. Like the way that we mask passwords (users can unmask them based on their needs)

[EnigmaRosa]

@ImanSharaf Is the intention here only to mask when the user is inputting the data (such as masking a credit card number after the user enters it, but before it is verified)? Or also to make sure that data is masked later on (such as when showing the user the last 4 digits of their credit card when selecting a saved payment method)? Either way, I think that this is not relevant to 1.8.x, since those are related more to storage and processing.

[elarlang]

Either way, I think that this is not relevant to 1.8.x, since those are related more to storage and processing.

This seems to addressed to my https://github.com/OWASP/ASVS/issues/1789#issuecomment-1814827812

If we can find examples and it is reasonable, then it should be heavily related with 1.8.1:

1.8.x requirements are for documenting security decisions. Proposed requirement itself, if it get to the document, should go to V8.

To accept the data from a user is part of the processing it, so it must be related with 1.8.1 and 1.8.2 to be analyzed, how it must be implemented to the application. Masking sensitive data can be just one option for potential protection level.

[ImanSharaf]

@EnigmaRosa we can mask it when we want to show them and the user can unmask them by clicking on an eye icon or a similar thing.

[elarlang]

@ImanSharaf do you think that requirements for either of those problems exist in ASVS today ?

I can answer myself that we don't cover those things at the moment.

Before jumping to recommendations or for possible requirements:

• do we have any other examples other than payment card number and password, which we should mask when entered?
• do we have any examples, what kind of sensitive data can be entered (let's not take password here, as it is covered by other requirements) to the application, but can not be displayed back to the output?

For a starter - to have a requirement - we should answers to those questions.

ping @ImanSharaf

[elarlang]

@EnigmaRosa we can mask it when we want to show them and the user can unmask them by clicking on an eye icon or a similar thing.

Can you give me an example when it makes sense, when you actually can do it or when it is implemented like you described.

For me it does not make sense - if some piece of information is so sensitive, that I can not show it to the screen, then - should I have it stored at all (if this is an option) or why I need to transfer it to the client by default? (to the UI, just somewhere hidden)

[ImanSharaf]

Masking sensitive data is not only a best practice but also often a requirement under various data protection laws and regulations like GDPR, HIPAA, and PCI DSS. Examples:

1. Social Security Numbers (SSNs): These are highly sensitive personal identifiers used in many countries. Displaying them fully can lead to identity theft.
2. Tax Identification Numbers: These numbers are sensitive as they are linked to an individual's financial and personal information.
3. Health Insurance Member IDs: Given the sensitivity of health-related information, these IDs should be protected.
4. Security Question Answers: The answers to security questions used for account recovery should be masked.
5. Personal Identification Numbers (PINs): Used for various verification processes, PINs should always be masked to maintain security.

For me it does not make sense - if some piece of information is so sensitive, that I can not show it to the screen, then - should I have it stored at all (if this is an option) or why I need to transfer it to the client by default? (to the UI, just somewhere hidden)

While it's important to store certain sensitive data for operational purposes, we must handle it with utmost care. Indeed, we do need to store such data due to various functional and regulatory requirements. However, displaying this information on the screen should be a controlled and on-demand process, governed by strict security protocols.

[elarlang]

There are no clear rule for sure that when you enter SSN somewhere you need to mask it. At least not in every country and not in every system.

So, I repeat my vision and proposal for potential requirement(s): masking is just one protection layer, the need to use this protection layer bust be analyzed and decided via 1.8.1 and at the moment required by 1.8.2 (it actually contains "privacy-enhancing technologies" part, where masking belongs).

In my ideal world 1.8.2 should be "implementation requirement", which means moved to V8. If there is clear material for new separate requirement, it must be also in V8.

I did some online-shopping during last week - and I saw card data masking... 0 times.

But to avoid the looping here, ping @tghosth for a change.

[ImanSharaf]

I did some online-shopping during last week - and I saw card data masking... 0 times.

1. You can see masking credit cards in every major North American shopping sites such as Amazon
2. ASVS is not about your experience as a retail user, I was engaged in several banking projects and in their clerk/admin portals (which retail users cannot see), they alway mask sensitive financial data such as SIN and Credit Card numbers. As I told you masking is requirement for PCI DSS. Let's wait for @tghosth answer.

[elarlang]

ASVS is not about your experience as a retail user...

This is not the way to go.

All I try to do is to validate here, if we set it as requirement, is it something which will be used or something which will be ignored.

[tghosth]

Doh, I was sure I had responded to this.

There are a few mechanisms here which I feel are getting confused.

1. Masking data as it is being entered into an input field. This could be a password and I think I have also seen this with credit cards although that is more rare.

2. Masking data being returned back to the user in the user interface. This should be irrelevant for passwords because they should never be returned to the user interface but for credit card numbers a partial/masked version may be returned. For this item, I am assuming that the full version is still being stored internally.

3. Masking data being stored in the application. In this case, only part of the data is actually being stored with the rest masked. I can see theoretical use cases for this as well (e.g. the actual sensitive data has been tokenized but you want to keep part of the original sensitive data for displaying in the user interface.

@ImanSharaf please can you clarify which you are refering to here

[tghosth]

Ping @ImanSharaf :)

[ImanSharaf]

Ping @ImanSharaf :)

My point is related to number 2.

Masking data being returned back to the user in the user interface. This should be irrelevant for passwords because they should never be returned to the user interface but for credit card numbers a partial/masked version may be returned. For this item, I am assuming that the full version is still being stored internally.

[tghosth]

Ok @ImanSharaf so something like:

Verify that the application only returns sensitive data such as credit card numbers to the application front end in a masked form and does not provide or show the full data item?

[elarlang]

What about applications that actually need to show them? Such as bank back-office.

[tghosth]

I think that is a valid question @ImanSharaf, how do we distinguish this?

[jmanico]

Here are other examples of data that should be considered for masking in a UI.

In secure coding practices, data masking in the UI is essential to protect sensitive information, particularly when displayed to users. Here’s a list of data types that should typically be considered for masking:

1. Personally Identifiable Information (PII) Social Security Numbers (SSNs) National Identification Numbers Passport Numbers Driver's License Numbers Taxpayer Identification Numbers Date of Birth (DOB) (or displaying only partial info, like year)

2. Financial Information Credit Card Numbers (mask all but the last 4 digits) Bank Account Numbers Payment Card Details (expiration date, security codes) Financial Transaction Details Income or Salary Information

3. Authentication and Security Data Passwords (should always be masked in input fields) PINs (Personal Identification Numbers) Secret Questions and Answers Security Tokens or Session Identifiers Multi-Factor Authentication (MFA) codes

4. Health Information (Protected Health Information - PHI) Medical Records Health Insurance Numbers Prescriptions Doctor or Hospital Names (in contexts where anonymity is required)

5. Sensitive Business Information Trade Secrets Confidential Agreements Proprietary Source Code Employee ID Numbers

6. Sensitive Application-Specific Data JWT Tokens (mask sensitive parts if presented in any UI) API Keys or Tokens Encryption Keys or Private Keys

7. Location and Contact Information Phone Numbers (display only partial number) Email Addresses (mask part of the email for non-authorized users) Home Addresses (display partially or use masking)

This is a common practice in secure coding and I support a requirement for this topic.

[jmanico]

In cases where applications, such as banking back-office systems, need to show sensitive data for legitimate business purposes, I think the approach should focus on secure display and access control. Access control is straight forward, principle of least privilege for data access. Secure display is about only displaying the minimal data needed for that business operation. Maybe a customer service rep has access to the entire credit card but only needs the last 4 to verify in a call for some reason.

[tghosth]

@elarlang @jmanico so maybe something like:

Verify that the application only returns the minimum required sensitive data for the application's functionality. For example, only returning some of the digits of a credit card number and not the full number. If the full data is absolutely required, it should be masked in the user interface unless the user specifically views it.

I would consider this L3

[jmanico]

I like this @tghosth 👍

[ImanSharaf]

@elarlang @jmanico so maybe something like:

Verify that the application only returns the minimum required sensitive data for the application's functionality. For example, only returning some of the digits of a credit card number and not the full number. If the full data is absolutely required, it should be masked in the user interface unless the user specifically views it.

I would consider this L3

It makes sense!

[elarlang]

Not sure if the explanation text should belong to the requirement or to some chapter text. The content is ok.

[tghosth]

@elarlang I think the requirement would be hard to understand without the explanation text and it doesn't make the requirement too long