Skip to main content
Cyber Risk Council
Category: Cryptography & Key Management

Hashing

Also known as: hash function, cryptographic hashing
Simply put

Hashing is the process of running data through a mathematical algorithm to produce a fixed-length value that represents the original data. Because the process is designed to work in only one direction, it is typically not feasible to reverse a hash back into the original input. Organizations often use hashing to verify data integrity and to protect stored information such as passwords.

Formal definition

Hashing applies a mathematical algorithm against an input of arbitrary size to produce a numeric or alphanumeric value of fixed, predetermined length that is representative of that data. In cryptographic contexts, hash functions are designed as one-way transformations that are computationally infeasible to reverse, making them suitable for integrity verification and credential protection rather than for recovering the original input. Note that hashing is a distinct concept in general data structures, where it is used to efficiently store and retrieve data via quick lookup; the cryptographic and data-structure uses share the underlying idea of mapping input to a representative value but serve different purposes and impose different design requirements.

Why it matters

Hashing underpins two of the most common security controls that a security leadership engagement will assess: data integrity verification and credential protection. Because a cryptographic hash produces a fixed-length value that is designed to be computationally infeasible to reverse, organizations can store a representation of a password rather than the password itself, and can detect whether a file or message has been altered by comparing hash values. When a virtual CISO reviews how an organization handles authentication and sensitive data at rest, the presence, absence, or misuse of hashing is often an early indicator of program maturity.

The governance concern is not merely whether hashing is used, but whether it is used correctly and for the right purpose. A common mistake that an experienced security leader will flag is treating hashing as if it were encryption; the two are distinct, since encryption is designed to be reversed with a key while cryptographic hashing is intentionally one-way. Another frequent point of confusion is conflating the cryptographic use of hashing with its unrelated use in general data structures, where hashing supports efficient storage and retrieval rather than security. These distinctions matter when advising engineering and compliance stakeholders, because design requirements differ substantially between the two uses.

The accountability for choosing, configuring, and maintaining hashing implementations remains with the client organization and its engineering and officer-level leadership. A virtual CISO typically advises on appropriate use and helps establish standards and policy, but generally does not perform the hands-on implementation or ongoing administration of these controls unless that work is explicitly contracted. The value of that advice depends on the organization's willingness to act on it and on the leader's access to the teams that build and operate the affected systems.

Who it's relevant to

Security and Engineering Leaders
Those responsible for how sensitive data and credentials are stored need to understand where hashing is appropriate and where it is being misapplied. A virtual CISO can help set standards distinguishing cryptographic hashing from encryption and from data-structure hashing, but the implementation and ongoing operation typically remain the responsibility of internal engineering teams.
Compliance and Risk Stakeholders
Because hashing supports data integrity and credential protection, its correct use often factors into readiness discussions for common frameworks and standards. It is important to treat hashing as one supporting control among many rather than as a guarantee of compliance or certification.
Buyers of Virtual or Fractional Security Leadership
Organizations engaging a vCISO should understand that the engagement typically covers strategy, governance, and advisory guidance on controls such as hashing, and generally does not include hands-on tool administration unless explicitly scoped. The accountability for security decisions remains with the organization and its officers.

Inside Hashing

One-Way Function
Hashing transforms input data of arbitrary size into a fixed-length output (the hash or digest) through a deterministic algorithm. The process is designed to be computationally infeasible to reverse, meaning the original input cannot practically be reconstructed from the hash alone.
Deterministic Output
The same input processed by the same hashing algorithm always produces the same hash value. This property enables verification use cases such as comparing a stored hash against a newly computed one.
Fixed-Length Digest
Regardless of input size, a given algorithm produces an output of consistent length. For example, algorithms in the SHA-2 family produce digests of defined bit lengths that do not vary with input size.
Collision Resistance
A desirable property whereby it is computationally difficult to find two distinct inputs that produce the same hash value. Weaknesses in this property are a primary reason older algorithms such as MD5 and SHA-1 are generally considered unsuitable for security-sensitive uses.
Salting (in Password Storage Context)
A unique random value added to input before hashing, commonly applied to passwords. Salting helps defend against precomputed lookup attacks by ensuring identical inputs produce different stored hashes.
Integrity Verification Use
Hashing is frequently used to confirm that data has not been altered in transit or storage, by comparing computed and expected digests. This differs from confidentiality, which hashing does not by itself provide.

Common questions

Answers to the questions practitioners most commonly ask about Hashing.

Is hashing the same as encryption?
No. This is a common misconception an expert would insist on correcting. Encryption is a reversible, two-way process designed so that data can be recovered using a key. Hashing is a one-way process: it produces a fixed-length output from input data and is not designed to be reversed to recover the original input. Because of this, hashing is not a substitute for encryption when you need to retrieve the original data later. A virtual CISO advising on data protection strategy will typically clarify which mechanism is appropriate for a given use case rather than treating the terms as interchangeable.
Does hashing a password mean it can never be recovered or cracked?
Not necessarily. While hashing is one-way and the original input is not directly recoverable from the hash, hashes can still be attacked through methods such as brute-force guessing, dictionary attacks, or precomputed lookups where weak or fast hashing is used without additional protections. Describing hashing as inherently unbreakable overstates its guarantees. In many engagements, security leadership will emphasize that the strength of a hashing approach depends on the algorithm chosen and on supporting measures rather than on hashing alone.
When should hashing be used instead of encryption in a system design?
Hashing is typically appropriate when you need to verify data rather than recover it, such as confirming a password matches or checking that a file has not been altered. Encryption is generally the right choice when the original data must be retrievable. In practice, the decision depends on the specific requirement, and a virtual CISO advising on architecture will usually help frame this as a business-risk and data-handling question rather than a purely technical one. Accountability for the final design choice generally remains with the client organization.
How does hashing support data integrity verification?
Hashing supports integrity verification by producing a consistent output for the same input, so a change to the input will typically produce a different hash. Comparing a stored or expected hash against a newly computed one can indicate whether data has been altered. This is often used in file verification and change-detection contexts. The value of this control in practice depends on how the reference hashes are stored and protected, which is a governance consideration a security leader would typically address in program design.
What factors influence the choice of a hashing approach for stored credentials?
Considerations typically include the algorithm's suitability for the intended purpose and the use of supporting techniques that make attacks more costly. A virtual CISO providing strategy and governance guidance may help evaluate these choices against organizational risk tolerance and relevant requirements, but implementation and administration of the chosen approach generally fall to the client's engineering or operations teams, since hands-on tool configuration is often out of scope for an advisory engagement unless explicitly contracted.
How does hashing relate to compliance or certification requirements?
Certain frameworks and standards may reference the protection of sensitive data, and hashing can be one supporting control where appropriate. However, using hashing does not by itself guarantee compliance or certification. A virtual CISO engagement can support readiness by helping map controls to requirements and identify gaps, but it does not assert or confer certification, and outcomes may vary by provider. The distinction between supporting readiness and claiming compliance is one an expert would insist on preserving.

Common misconceptions

Hashing is a form of encryption and can be decrypted to recover the original data.
Hashing and encryption are distinct. Encryption is designed to be reversible with a key, whereas hashing is intended as a one-way transformation with no key to reverse it. Hashing does not provide confidentiality in the way encryption does, and treating the two as interchangeable is a mistake an expert would correct.
Any hashing algorithm is adequate as long as it produces a digest.
Algorithm choice matters significantly. Older algorithms such as MD5 and SHA-1 have known weaknesses in collision resistance and are generally considered unsuitable for security-sensitive purposes. The appropriate algorithm depends on the use case, and password storage in particular has different requirements than simple integrity checks.
Hashing passwords alone makes them secure.
A plain hash of a password may still be vulnerable to precomputed and dictionary-based attacks. Practices such as salting, and use of algorithms designed to be computationally costly for password contexts, are typically needed to strengthen stored password protection. The value of any approach also depends on correct implementation.

Best practices

Select hashing algorithms appropriate to the use case, and avoid algorithms with known weaknesses such as MD5 and SHA-1 for security-sensitive purposes.
Apply unique salts when hashing passwords to reduce exposure to precomputed lookup attacks, and follow implementation practices suited to password storage rather than general-purpose integrity hashing.
Use hashing for its intended purpose of integrity verification or one-way storage, and do not rely on it to provide confidentiality, which requires encryption instead.
Verify integrity by comparing computed digests against trusted expected values, and treat any mismatch as an indication of alteration.
Periodically review the algorithms in use as cryptographic guidance evolves, since algorithms considered adequate today may be deprecated over time.
Frame algorithm and implementation choices as governance and risk decisions with documented rationale, recognizing that the client organization retains accountability for its data protection controls.