Protecting sensitive data: classify, minimise, mask

A support screen shows every customer’s full card number, date of birth and home address to 120 agents, and the same API response also feeds the mobile app, an analytics script and the request log. Nothing has been stolen yet, but each customer’s data now sits in four more places than any task needed, and each copy is one more way to lose it. The A04:2025 prevention list starts here: know which data is sensitive, and do not keep what you do not need.

You will sort an application’s data into four protection levels with a rule for each, keep less of it by truncating, masking and tokenising, and check in a recorded run that a masked value never gives the original away.

Classify first: four levels, each with its own rules

Before choosing any control, decide how much each field matters. ASVS 5.0.0 requirement 14.1.1 asks that sensitive data be identified and sorted into protection levels, and 14.1.2 that every level have written rules covering encryption, integrity, retention, logging and access to those logs. Four levels are enough to start, and the rules matter more than the names:

Read the restricted row first: a card number appears in full nowhere a person looks. ASVS 14.1.1 adds a trap that catches many teams: data that is merely encoded is still data in the clear, so a Base64 string or the readable payload of a JWT carries the level of whatever it holds. And a field that nobody has classified is the riskiest of all, because no rule applies to it. Treat it as confidential until someone decides.

Minimise first, then mask what you must show

The cheapest protection is data you do not have. The A04:2025 list says it plainly: data that is not kept cannot be stolen. Minimisingdata minimisation: Collecting, keeping and showing only the personal data a task needs, for only as long as it needs it. Data that is not kept cannot be stolen or leaked. has three moves, collect less, keep less and show less, and four techniques do most of the work:

• Truncate: keep only part of a value, such as the last four digits of a card, when the rest is never needed again.
• Mask: keep the value but show it obscured, such as c********@mail.example, with an explicit action to reveal it.
• Tokenise: replace the value with a random tokentokenisation: Replacing a sensitive value, such as a card number, with a random token and keeping the real value in a separate vault with its own access control. The token reveals nothing on its own. and keep the real one in a separate vault, often a payment provider’s.
• Keyed hash: store an HMAC of the value with a key held outside the database, when you only need to match equal values: a keyed hashkeyed hash: A hash computed with a secret key, such as HMAC-SHA-256. Equal inputs give equal outputs while the key stays the same, but without the key nobody can rebuild the values by hashing guesses. cannot be rebuilt without the key.

ASVS 14.2.6 asks for the masked form by default: return only the part of a value that a feature needs, and if the whole value is needed, obscure it until the user asks. The program below applies the techniques to 1,000 made-up customers and checks two promises: no masked value contains the original, and a stored token cannot be turned back into the phone number by trying every number with the same first five digits:

# Four ways to keep less of a value, tried on 1,000 made-up customers (seeded, so every run makes the same ones):
# truncate a card number to its last four digits, mask an email address and a phone number for display, and turn a
# phone number into a keyed token that can still be matched. The checks at the end are the point: no masked value may
# contain the original, and a token must not be reversible by trying every possible number.
import hashlib
import hmac
import random
import secrets

def last_four(card):
    return "**** " + card[-4:]

def mask_email(email):
    name, domain = email.split("@")
    return name[0] + "*" * (len(name) - 1) + "@" + domain

def mask_phone(phone):
    return "*" * (len(phone) - 2) + phone[-2:]

KEY = secrets.token_bytes(32)  # held outside the database, in a secrets manager, in a real app

def keyed_token(phone):
    return hmac.new(KEY, phone.encode(), hashlib.sha256).hexdigest()

def plain_hash(phone):
    return hashlib.sha256(phone.encode()).hexdigest()

rng = random.Random(7)  # test data only: never use the random module for anything secret
people = []
for i in range(1000):
    card = "".join(str(rng.randrange(10)) for _ in range(16))
    phone = "98765" + "".join(str(rng.randrange(10)) for _ in range(5))
    people.append({"card": card, "email": f"customer{i}@mail.example", "phone": phone})

print("customer 0, as stored :", people[0]["card"], people[0]["email"], people[0]["phone"])
print("customer 0, as shown  :", last_four(people[0]["card"]), mask_email(people[0]["email"]), mask_phone(people[0]["phone"]))

leaks = sum(p["card"] in last_four(p["card"]) or p["phone"] in mask_phone(p["phone"]) or p["email"] in mask_email(p["email"]) for p in people)
print("masked values that still contain the original:", leaks, "of", len(people))

same = keyed_token(people[0]["phone"]) == keyed_token(people[0]["phone"])
print("the same phone gives the same keyed token, so duplicates can be found:", same)

# Can the stored form be turned back into the number by trying every number that starts 98765?
target = people[0]["phone"]
weak = plain_hash(target)
tries = next(n for n in range(100_000) if plain_hash(f"98765{n:05d}") == weak) + 1
print(f"plain SHA-256: found the number again after {tries:,} of 100,000 tries")
stored = keyed_token(target)
guessed_key = secrets.token_bytes(32)
hits = sum(hmac.new(guessed_key, f"98765{n:05d}".encode(), hashlib.sha256).hexdigest() == stored for n in range(100_000))
print(f"keyed token, tried without the key: {hits} matches in 100,000 tries")

customer 0, as stored : 5260181590830166 customer0@mail.example 9876513186
customer 0, as shown  : **** 0166 c********@mail.example ********86
masked values that still contain the original: 0 of 1000
the same phone gives the same keyed token, so duplicates can be found: True
plain SHA-256: found the number again after 13,187 of 100,000 tries
keyed token, tried without the key: 0 matches in 100,000 tries

None of the 1,000 masked values held its original. The last two lines are the reason to key the hash. A plain SHA-256 of the phone number gave the number back after 13,187 tries, because the program only had to hash the 100,000 numbers that start with 98765 and compare. Without the key, 100,000 tries found nothing. A plain hash of a small set of values, such as phone numbers, PINs or dates of birth, is a table anyone can rebuild, not a protection.

Which technique fits depends on what the feature needs. Answer three questions about a field of yours:

What you keep can still leave through URLs, logs, caches, browser storage, third parties, exports, backups and file metadata, and each copy needs a retention rule, which India’s DPDP Act makes a legal duty.

Where sensitive data leaks, traced with a data map Pro: opens with a Pro, Premium or Ultimate pass

Encrypting what you keep, with a key outside the database Pro: opens with a Pro, Premium or Ultimate pass

Retention and deletion, with India's DPDP Act Pro: opens with a Pro, Premium or Ultimate pass

Practise: a profile that shows only what each reader needs

Write the masking functions and a profile response that gives each kind of reader only the fields their task needs. The sample tests run in your browser:

// Starter: every reader gets the whole record. Write the masks and return only what each role needs.

export function maskCard(card) {
  return card;
}

export function maskEmail(email) {
  return email;
}

export function maskPhone(phone) {
  return phone;
}

export function profileFor(user, viewer) {
  return { ...user };
}

import { test, assert } from 'mysmartcopilot:test';
import { maskCard, maskEmail, maskPhone, profileFor } from './profile.mjs';

const asha = {
  name: 'Asha Rao',
  email: 'asha@mail.example',
  phone: '+91 98765 43210',
  card: '4111 1111 1111 1234',
  birthDate: '1994-02-11',
  address: '12 Lake Road, Pune',
  city: 'Pune',
};

test('the masks keep only what is shown', () => {
  assert.equal(maskCard('4111 1111 1111 1234'), '**** 1234');
  assert.equal(maskCard('4111-1111-1111-9876'), '**** 9876', 'dashes are ignored');
  assert.equal(maskEmail('asha@mail.example'), 'a***@mail.example');
  assert.equal(maskEmail('k@mail.example'), '*@mail.example', 'a one-character name');
  assert.equal(maskPhone('+91 98765 43210'), '**********10');
  assert.equal(maskPhone('0123'), '**23');
});

test('the customer sees their own data, but never the full card', () => {
  assert.deepEqual(profileFor(asha, { role: 'self' }), {
    name: 'Asha Rao',
    email: 'asha@mail.example',
    phone: '+91 98765 43210',
    address: '12 Lake Road, Pune',
    card: '**** 1234',
  });
});

test('support sees masked values unless a field is revealed', () => {
  assert.deepEqual(profileFor(asha, { role: 'support' }), { name: 'Asha Rao', email: 'a***@mail.example', phone: '**********10', card: '**** 1234', revealed: [] });
  const shown = profileFor(asha, { role: 'support', reveal: ['phone', 'card', 'birthDate'] });
  assert.equal(shown.phone, '+91 98765 43210', 'phone can be revealed');
  assert.equal(shown.card, '**** 1234', 'the card stays masked');
  assert.equal(shown.birthDate, undefined, 'fields support never sees cannot be revealed');
  assert.deepEqual(shown.revealed, ['phone']);
});

test('analytics gets the city and nothing else', () => {
  assert.deepEqual(profileFor(asha, { role: 'analytics' }), { city: 'Pune' });
});

test('no response contains the full card number, and unknown roles are refused', () => {
  for (const role of ['self', 'support', 'analytics']) {
    const text = JSON.stringify(profileFor(asha, { role, reveal: ['card', 'email', 'phone'] }));
    assert.ok(!text.includes('1111'), `the ${role} response holds no hidden card digits`);
  }
  assert.throws(() => profileFor(asha, { role: 'marketing' }), undefined, 'an unknown role');
  const later = profileFor({ ...asha, taxId: 'TX-77810' }, { role: 'self' });
  assert.equal(later.taxId, undefined, 'a field added later is not sent by default');
});

The self-check below asks about classifying and minimising, starting with whichever of the two your answers show you know less well:

Interview questions

Key takeaways

• Give every field one of four levels with written rules; encoded data, such as a JWT payload, keeps its level.
• Data you do not keep cannot be stolen: collect less, keep less and show less before protecting anything.
• Truncate what you never need in full, mask what people see, tokenise through a vault, and key the hash you match on.
• Test masking as a property: none of 1,000 masked values contained its original.
• An unkeyed hash of a phone number came back after 13,187 tries, so a hash of a small set of values needs a key.