Low-Entropy Identifier

A low-entropy identifier comes from a small or predictable value space, such as an SSN, phone number, or card number. Because attackers can guess many possible values, these fields are weak protection candidates unless a secret salt or stronger control is added before hashing.

Expanded Definition

A low-entropy identifier is any identifier drawn from a small or predictable value space, which makes it easier to guess, enumerate, or brute-force. Common examples include SSNs, phone numbers, and card numbers, where the search space is far smaller than a true secret and often follows public formatting rules.

The key boundary is that an identifier can still be useful for lookup or correlation while remaining weak as a protection mechanism. Hashing alone does not change that if the input space is guessable. A salt, rate limiting, and stronger verification all change the security properties, but the identifier itself remains low entropy. In practice, this is why a low-entropy identifier should not be treated as a stand-alone safeguard for masking, tokenisation, or account recovery workflows.

Industry usage is fairly consistent on the core idea, though teams sometimes blur “unique” with “hard to guess.” A value can be globally unique and still be low entropy if attackers can predict the format and test likely candidates quickly. For a broader control perspective on predictable identifiers and the need for stronger handling, the OWASP Non-Human Identity Top 10 is useful when identifiers are used inside automated access paths.

Examples and Use Cases

Low-entropy identifiers show up anywhere organisations rely on predictable values as lookup keys, customer matching fields, or recovery inputs. The security issue is not the identifier’s existence, but the temptation to use it as if predictability were a defense.

• Customer verification flows that accept a phone number, date of birth, or partial card number as a lookup factor.
• Hash-based storage designs where a low-entropy field is stored without a secret salt, leaving the value space easy to test.
• Legacy integration points that use SSNs or account numbers as external references and expose them through logs, exports, or support tooling.
• Fraud or onboarding systems that rely on predictable identifiers for matching records across vendors or internal databases.

A common implementation tradeoff is convenience versus resistance to guessing. Low-entropy identifiers are easy to collect and index, but they are poor candidates for secrecy because attackers can precompute or enumerate likely values. That means the safer design choice is usually to separate the identifier from any security decision and add a stronger control around it.

Where predictable values are embedded in tooling or automation, the operational risk rises because the same identifier can be reused across many systems. NHIMG research on hard-coded secrets and token exposure shows how broadly exposed values become difficult to contain once they are embedded in workflows, code, or extensions.

Security Implications

The main security problem is false trust. If a low-entropy identifier is used to hide data, protect records, or serve as a pseudo-secret, attackers can often guess enough candidates to test the space efficiently. That weakens confidentiality, makes account or record enumeration easier, and can turn a benign identifier into a reusable access path.

This is especially dangerous when organisations build workflows around predictable identifiers and then expose them through support channels, URLs, APIs, or logs. A determined attacker does not need to break cryptography if the system gives away a small enough search space. Once enumeration is possible, bulk discovery and abuse become much easier than many teams expect.

Failure mechanism: the identifier’s predictability enables brute-force testing, correlation, or precomputation, especially when hashing, masking, or lookup logic lacks a secret salt or rate limits.

Impact: exposed records, weakened masking, easier credential or account discovery, and higher fraud or privacy risk. NHIMG data indicates that 79% of organisations have experienced secrets leaks, with 77% of those incidents resulting in tangible damage, which is consistent with the broader pattern that exposed values often become operationally costly.

Security, Operational and Governance Implications

From a governance perspective, the practical question is whether the identifier is being used as an identity label, a matching key, or a protection control. Those roles are not interchangeable. A predictable field may be acceptable for record lookup, but it should not be allowed to stand in for access control, secrecy, or verification.

Operationally, teams should expect low-entropy identifiers to age badly when they are copied into logs, shared externally, or reused across systems. They also become harder to govern when ownership is split between application, data, and support teams, because each team may assume someone else is protecting the downstream exposure.

Where automation consumes these identifiers at scale, the risk is amplified by volume rather than novelty. The safest posture is to treat low-entropy identifiers as public or semi-public data unless a separate control meaningfully changes the threat model, such as a secret salt, strong rate limiting, or a different credential altogether.

Risk and Threat Considerations

Low-entropy identifiers create a predictable attack surface because their value space is small enough for enumeration, correlation, and brute-force testing. That makes them attractive when attackers want to discover accounts, validate records, or abuse weak hashing and masking designs.

Failure mechanism: the attacker exploits predictability, predictable formatting, or partial exposure to test candidate values at scale, often against weak lookup endpoints or unsalted hashes.

Impact: privacy loss, record discovery, account enumeration, and broader downstream abuse when the identifier is reused as a quasi-secret or recovery factor.

Related resources from NHI Mgmt Group

• What is the difference between a low-assurance recovery question and a strong recovery factor?
• When should organisations rethink email as the primary identifier?
• Should organisations prioritise code-first or low-code agent builders?
• How should security teams inventory AI agents across SaaS, cloud, and low-code platforms?