Private Preview
Join Waitlist →

K-Anonymity Explained

The privacy technique behind breach checking

3 min readAuthor: Redactorr Support Team · [email protected]Last reviewed: May 2026

Outcome

Understand k-anonymity well enough to use breach-check style tools without revealing the full secret.

Your progress

Mark each step as you complete it. This is saved only in this browser.

0 / 3 steps complete

Before you start

Do not paste live passwords, secrets, or private tokens into support messages.
Know whether you are checking a password, explaining privacy math, or debugging a tool result.
Use fake examples when learning the concept.

Visual frame

Review asset

K-anonymity explained storyboard

Synthetic k-anonymity frame only. It explains the concept as a privacy model and avoids claiming automatic anonymity.

GroupMinimum size
IdentifiersQuasi fields
LimitNot a guarantee

Synthetic frame

Group size

K means how many similar records exist.

Record AGroup of 5
Record BUnique combination
GoalReduce uniqueness
K-anonymity is about reducing uniqueness, not deleting all risk.

Partial-match privacy frame

A concept frame showing full secret, partial prefix, remote lookup boundary, and local comparison as separate steps.

BoundaryWhat the article can and cannot safely claim.
Next routeThe playbook or reference page that should handle the actual task.
Safe contextWhat support can receive without raw originals by default.

Guided steps

Follow the task, then check the result.

Read the boundary before acting

Start with what the article says is available, measured, preview-only, or not a product claim. Do not treat reference material as permission to send raw private content to support or external tools.

Article boundary note followed by the next task route.
Success check: You know whether this article is a task guide, a reference page, or a product-boundary note.

Apply the concept to a safe checker workflow

Use the article to understand why only partial data should be compared in breach-style checks. If you are checking a real credential, use the relevant tool workflow and never send the secret to support.

Partial-match privacy frame
Success check: You understand the privacy boundary and can use the checker without exposing the full value.

Prepare safe support context if something disagrees

If the article and product screen do not match, describe the route, step, browser, and symptom. Do not paste raw original document text, secrets, restoration material, or private files by default.

Safe support bundle with route, symptom, and consent-only fields separated.
Success check: Any support description avoids raw private content unless you explicitly consent.

Branch questions

Completion check

You know whether this page is instructional, reference-only, or a product-boundary note.
You opened a task playbook when step-by-step guidance was needed.
Any support escalation avoids raw document text, secrets, files, and restoration material by default.

Support boundary

Support can use by default

  • Tool name and route.
  • Concept question or error category.
  • No full password, token, or secret by default.
  • Intent ID
  • Article slug
  • App route
  • Browser and viewport

Requires your consent

  • User-written description
  • Email address
  • Explicit attachment
  • Redacted sample
  • Support bundle previewed to the user

Not collected by default

  • Raw original document text
  • Full local file paths
  • Pasted private content
  • Unmasked screenshots
  • Replay capture

Safe support summary

Copy a scrubbed handoff.

Redactorr KB support summary

Article: /knowledge-base/k-anonymity
Selected issue: A user is unsure whether a checker sends full secrets.
Playbook progress: 0/3 steps marked complete

Safe context to include:
- Tool name and route.
- Concept question or error category.
- No full password, token, or secret by default.
- Intent ID
- Article slug
- App route
- Browser and viewport

Requires explicit consent:
- User-written description
- Email address
- Explicit attachment
- Redacted sample
- Support bundle previewed to the user

Do not include by default:
- Raw original document text
- Full local file paths
- Pasted private content
- Unmasked screenshots
- Replay capture

User note:
- Describe the step and symptom without pasting raw document text, secrets, files, or restoration material.

Article details

K-Anonymity: Privacy Through Ambiguity

How do you check if a password has been breached without revealing the password itself? This is the paradox that k-anonymity solves.

The Problem

Naive Approach: Send your password to a server, server checks its database of breached passwords, returns yes/no.

Why This Fails: You just sent your password over the internet to a third party. Even if you trust them, what if their server is compromised? What if they log your request?

You've exposed the very thing you were trying to protect.

The K-Anonymity Solution

K-anonymity uses a clever trick: partial matching.

Instead of sending your full password, you send only a small part of a cryptographic hash. The server responds with all passwords that match that partial hash, and your browser checks locally for an exact match.

The Process (Simple)

Hash your password locally:

1 / 1

The browser turns the password into a SHA-1 hash.

Send only the first 5 characters:

1 / 1

The browser sends the hash prefix, not the original password.

Server responds with matching hash suffixes

1 / 1

The response contains candidate suffixes for that prefix.

Your browser checks for an exact match locally

1 / 1

The browser compares the returned suffixes with the full hash without sending the full hash back.

What the server learns: Someone is checking a password with a particular hash prefix.

What the server doesn't learn: Which specific password, or even which of the 800+ possibilities.

Why "K-Anonymity"?

The "k" in k-anonymity represents the size of the anonymity set - how many other possibilities you're hiding among.

In breach-check workflows, the anonymity set is usually hundreds of possible hash suffixes for the same prefix.

Each 5-character hash prefix can match many different entries in the breach database. Your browser receives the candidate suffixes and checks locally for an exact match.

The larger k is, the more anonymous you are.

Real-World Analogy

Bad Approach (No Anonymity): Walking into a police station and asking, "Do you have a warrant for John Smith at 123 Main St, DOB 1/15/1990?"

K-Anonymity Approach: Asking, "Do you have any warrants for someone with initials J.S.?" The officer hands you a list of 800 people with those initials, and you check privately if your full name is on the list.

The officer learns: Someone is checking for initials J.S. The officer doesn't learn: Which specific person you're inquiring about.

Practical Use: Breach Checker

When you use Redactorr's Breach Checker:

Your password is hashed in your browser (never sent in plaintext)

Only the first 5 characters of the hash are sent to HaveIBeenPwned (HIBP)

HIBP returns ~800 hash suffixes that match that prefix

Your browser compares these locally to find a match

HIBP never sees your actual password or even the full hash

1 / 5

Privacy preserved. Breach checked.

Privacy Benefit

With SHA-1 hashes (40 hex characters) and 5-character prefixes:

  • Total possible hashes: 16^40 (astronomically large)
  • Total possible 5-char prefixes: 16^5 = 1,048,576
  • Returned candidate set: Many suffixes can share the same prefix

Conclusion: The breach-check service sees a prefix, not the full password or full hash. This reduces exposure, but it is not full anonymity.

Limitations

K-anonymity is not perfect:

Frequency attacks: If your password is extremely common (e.g., "password123"), the attacker might guess you're checking it because it appears in almost every prefix query.

Correlation attacks: If an attacker monitors multiple queries from the same IP and sees overlapping prefixes, they could narrow down possibilities.

Not full anonymity: The server still knows you checked something. For truly sensitive passwords (e.g., master passwords for password managers), consider offline breach databases.

1 / 3

For most breach-check use cases, k-anonymity is a strong improvement over sending the original password or full hash to a server.

Why Redactorr Uses K-Anonymity

K-anonymity principle: The breach check sends only a hash prefix, not the full password, API key, or credential.

Widely used pattern: K-anonymity for password breach checking is a well-known pattern used by HaveIBeenPwned.

Auditable: The protocol is simple and auditable. Open your browser's DevTools, watch the network requests, and verify that only hash prefixes are transmitted.

Still stuck?

Copy a safe article handoff.

Start support with the article, the issue, and safe context. Raw document text, files, restoration material, and unredacted screenshots stay out unless you explicitly choose otherwise.

Support can start here
  • Article slug
  • Selected issue
  • Screen name
  • Action name
Redactorr support case

Source: Article playbook: k-anonymity
Route: /knowledge-base/k-anonymity
Selected issue: A user is unsure whether a checker sends full secrets.

Safe context:
- Tool name and route.
- Concept question or error category.
- No full password, token, or secret by default.
- Article slug
- Selected issue
- Screen name or article section
- Action name
- Browser and viewport

Only include with explicit consent:
- User-written description
- Email address
- Explicit attachment
- Redacted sample
- Support bundle previewed to the user

Do not include by default:
- Raw original document text
- Full local file paths
- Pasted private content
- Unmasked screenshots
- Replay capture
- Hidden diagnostic uploads

User note:
- Describe what you tried and what happened. Do not paste raw document text, secrets, files, restoration material, or unredacted screenshots.

Support case builder

One case format, wherever you start.

This is the same support case shape used by diagnostics and article handoffs.

Safe to include
  • Tool name and route.
  • Concept question or error category.
  • No full password, token, or secret by default.
  • Article slug
  • Selected issue
  • Screen name or article section
Consent boundary

Private material belongs behind an explicit consent step, not in the initial case.

6 default exclusions

Before you copy0/4 ready
Open safe support guide