The knowledge factor (something you know)¶
Most discussions of biometrics jump straight to something you are — iris, palm, voice. In real deployments, especially in regulated ones, biometrics are typically combined with at least one other factor: something you have (a device, a hardware key) and / or something you know (a memorized secret).
BioTone treats the knowledge factor as a first-class part of a combined verification, not an afterthought. This page explains how it works, what design choices we made, and why.
What we mean by "knowledge factor"¶
Two complementary signals, both rooted in NIST SP 800-63B's definition of a memorized secret:
-
A memorized secret — a short string the user picks at enrollment. We deliberately avoid the word "password" for this, because "password" carries assumptions (server-side hash, recovery email, complex character classes) that do not apply here.
-
One or more visual anchors — a chosen color, a chosen playing card, or another small palette of high-recognition, low-typing prompts that the user picked at enrollment. Anchors are easier to remember reliably than long strings, and they bind the verification to the user's prior enrollment on a specific device.
Both are evaluated on the user's device, not on our servers.
What leaves the device¶
Biometrics tutorials often debate "where does the template live?" The same question applies to the knowledge factor:
- Never sent to our servers in the clear — the memorized secret, the anchor color, or the anchor card.
- Stored on the device (in the platform secure store, scoped per user) — a salted, one-way hash of the memorized secret, plus the anchor identifiers chosen at enrollment.
- Sent for audit only — whether the verification ran, whether it passed or failed, the policy mode in effect, and optional metadata such as the length (not the value) of the memorized secret. This supports zero-trust attestation and operator reporting without centralizing long-lived secrets.
The result: a breach of our backend gives an attacker no useful material for impersonating any user's knowledge factor. Recovery is local to the user's device and runs through the same enrollment flow.
Configuring it as an operator¶
Operators using BioTone for workforce or customer authentication can set the knowledge factor to one of three modes per policy:
| Mode | Behavior |
|---|---|
| Off | No knowledge step in combined verification. |
| Optional | If the user has enrolled a knowledge factor on the device, the step appears and must pass. If they haven't enrolled, the step is skipped. |
| Required | Combined verification will not start until enrollment exists on the device. |
Additional toggles cover minimum length for the memorized secret, whether to require a letter + digit mix, and which anchor types (color, card, both) participate.
Why it is a useful factor in a biometrics-first product¶
It is tempting to argue that a sufficiently strong biometric makes something you know unnecessary. In practice it does not, for three reasons.
- Independence. A face spoof, a synthetic voice, or a stolen palm photo does not give the attacker the user's memorized secret or chosen anchor. Combining factors from different categories is what makes "multi-factor" actually multi-factor.
- Deliberate friction. A short knowledge step gives the user a moment of conscious intent before a high-value action — an underrated property in social-engineering and coercion threat models.
- Standards alignment. NIST SP 800-63B treats memorized secrets as a first-class authenticator type, with explicit rules on minimum length, no unbounded online guessing, and rate limiting. Building the same protections on a biometric-only flow is harder than just including a small knowledge step.
See also¶
- Glossary — definitions for AAL, MFA, something you know / have / are.
- Standards and frameworks — the NIST SP 800-63 series and the FIDO2 model, which are the public references the design above maps to.
- Privacy-Preserving Biometrics — broader treatment of "what should leave the device" for biometric data.