Category: Authentication Factors

Something You Know

Also known as: Knowledge Factor, Knowledge-Based Authentication Factor

Simply put

"Something you know" refers to a piece of secret information that a person must supply to prove their identity, such as a password, PIN, or the answer to a security question. Because it relies on information kept in a user's memory, it is one of the common categories of authentication factors. It differs from proving identity with a physical device you have or a biometric trait that is part of you.

Formal definition

"Something you know" is the knowledge factor category in authentication, referring to a secret the claimant must present to verify an asserted identity during the authentication step (distinct from identification and from subsequent authorization decisions). Typical instances include passwords, passphrases, PINs, and knowledge-based challenge responses. It is one of three commonly cited factor categories alongside possession factors ("something you have") and inherence factors ("something you are"), and combining a knowledge factor with a factor from a different category is what generally constitutes multi-factor authentication. Note that the provided evidence packet does not contain IAM-specific source material on this term; the categorization above reflects standard practitioner usage rather than the supplied sources, which are unrelated to identity and access management.

Why it matters

The knowledge factor is the oldest and still most widely deployed category of authentication, and its limitations shape much of modern IAM strategy. Because a secret held in memory can be guessed, phished, reused across services, shared, or intercepted, systems that rely on a knowledge factor alone are exposed to credential-based attacks such as phishing, brute forcing, and credential stuffing. Understanding "something you know" as a distinct category is what allows architects to reason about why single-factor password authentication is generally considered weak and why layering factors from different categories improves assurance.

The concept is also central to defining multi-factor authentication correctly. Combining a knowledge factor with a possession factor ("something you have") or an inherence factor ("something you are") is what generally constitutes MFA; combining two knowledge factors, such as a password plus a security question, does not add a genuinely independent category and provides limited additional protection. Practitioners who blur these distinctions risk designing controls that appear to be multi-factor on paper but share the same failure modes in practice.

Because the knowledge factor depends on human memory and secrecy, much of the recent momentum in authentication has been toward reducing or eliminating reliance on it. Framing "something you know" precisely helps teams evaluate whether a proposed control genuinely diversifies factor categories or merely stacks additional secrets that a single phishing event could compromise.

Who it's relevant to

IAM Engineers and Security Architects

Those designing authentication flows need to treat the knowledge factor as one category among three and ensure that any multi-factor design combines factors from genuinely different categories rather than stacking two knowledge-based secrets. This informs decisions about password policies, secure storage of secrets, and where to introduce possession or inherence factors.

System Administrators

Administrators who operate authentication services manage the day-to-day handling of knowledge factors, including password reset processes, security question configuration, and the interaction between these secrets and other factors during login. Understanding the category's inherent weaknesses helps prioritize hardening and user education.

Compliance Officers and Governance Leads

Those assessing whether an environment meets multi-factor requirements should verify that controls counted toward MFA actually draw on distinct factor categories. A password paired with a security question, for example, may not satisfy the intent of a multi-factor mandate even if two credentials are collected.

Inside Something You Know

Knowledge Factor

The authentication factor category to which 'something you know' belongs, alongside possession (something you have) and inherence (something you are). It relies on secret information that only the legitimate principal should be able to reproduce during authentication.

Passwords and Passphrases

The most common instances of a knowledge factor, consisting of a secret string the user supplies to prove identity. Passphrases are typically longer, multi-word variants intended to increase entropy while remaining memorable.

PINs

Numeric secrets, often shorter than passwords, used as a knowledge factor. In many deployments a PIN unlocks a local possession-based credential (such as a device) rather than being transmitted, so its security role depends on context.

Security Questions

Pre-registered question-and-answer pairs used as a knowledge factor, typically for account recovery or as a supplementary check. Their secrecy is often weak because answers may be guessable or publicly discoverable.

Shared Secret Nature

Knowledge factors are generally secrets that must be known to, or verifiable by, the relying system. This introduces storage and handling concerns such as hashing and protection against disclosure, distinct from how possession or inherence factors are verified.

Common questions

Answers to the questions practitioners most commonly ask about Something You Know.

Is a knowledge factor the same thing as a password?

No. A password is the most common example of a knowledge factor, but the category also includes PINs, passphrases, and answers to knowledge-based questions. "Something you know" refers to any secret the user must recall and present, not exclusively to passwords.

Does adding a second knowledge factor, such as a security question on top of a password, count as multi-factor authentication?

No. MFA requires factors from distinct categories, typically knowledge (something you know), possession (something you have), and inherence (something you are). Combining a password with a security question uses two knowledge factors, so it is not MFA; it remains single-factor from a category standpoint, even though it presents two challenges.

How should knowledge factors be stored on the server side?

In most deployments, knowledge factors such as passwords are not stored in plaintext or as reversible ciphertext. They are typically stored as salted hashes produced by a password-hashing function. Note that hashing is distinct from encryption: a hash is designed to be non-reversible, so the original secret is not intended to be recoverable. Specific algorithm and parameter choices depend on your security requirements and platform.

Where does a knowledge factor fit in a step-up authentication flow?

In many configurations a knowledge factor establishes the initial authenticated session, and step-up authentication then adds a stronger or different-category factor when the user attempts a sensitive action. Depending on policy, the step-up challenge may be a possession or inherence factor rather than another knowledge factor, since repeating the same category typically adds limited assurance.

Are knowledge factors required in a passwordless deployment?

Not necessarily. Passwordless authentication aims to remove the shared-secret knowledge factor, typically relying on possession and inherence factors instead. However, some passwordless implementations still use a locally verified PIN to unlock an authenticator; in that pattern the PIN is verified on the device rather than transmitted as a server-side shared secret, which is a different trust model from a traditional password. Behavior varies by implementation.

What operational controls are commonly applied to knowledge factors during authentication?

Depending on configuration, common controls include rate limiting and lockout on repeated failures, protection against replay and interception in transit, and policies governing secret complexity, rotation, and reuse. These are runtime enforcement concerns and should be distinguished from governance-side lifecycle activities such as credential provisioning and access certification. The exact controls available depend on the vendor and standard profile in use.

Common misconceptions

Using a password means you are using multi-factor authentication.

A password is a single knowledge factor. MFA requires factors from two or more distinct categories (knowledge, possession, inherence). Combining a password with a security question is still single-category and typically does not qualify as true MFA.

A knowledge factor alone provides authorization.

Supplying a correct password contributes only to authentication, verifying who the principal is. What that principal may then do is determined separately by authorization, which is a distinct step from proving a knowledge factor.

Longer or more complex knowledge factors are inherently secure.

Complexity can raise entropy, but knowledge factors remain vulnerable to phishing, reuse, and disclosure regardless of length. Security also depends on how the secret is stored, transmitted, and recovered, and in most deployments knowledge factors are strengthened by pairing them with other factors.

Best practices

Treat knowledge factors as a single factor and combine them with a factor from a different category (possession or inherence) when stronger assurance is required.

Store password-type secrets using appropriate one-way hashing rather than reversible or plaintext storage, and protect them in transit.

Prefer longer passphrases over short complex strings where the platform supports it, to increase entropy without harming usability.

Avoid relying on security questions as a primary or standalone knowledge factor, since answers are often guessable or publicly discoverable; where used, treat them as low-assurance supplements.

Clarify the actual security role of PINs in your deployment, distinguishing a PIN that unlocks a local possession-based credential from a PIN transmitted as a standalone secret.

Keep authentication with a knowledge factor separate from authorization decisions, so that verifying the secret does not by itself grant access rights.