Encryption, hashing and masking are often treated as interchangeable ways to "protect" data, yet they fail in completely different ways, and picking the wrong one leaves passwords recoverable, test databases full of real customers, or dashboards that leak values to anyone who can write a query. Encryption is reversible by anyone holding the key. Hashing is designed to be one-way and is only as strong as the input space and the work factor. Masking changes what a user sees or what a copy contains, and dynamic masking leaves the real data untouched underneath. This guide compares the three on reversibility, key dependence, attacks, use cases and legal status under GDPR, with a selection table and worked scenarios. It is for application, data and security engineers and privacy teams deciding how to protect a specific field. It goes beyond the single-technique guides: for the mechanics of each, see the Encryption Guide, the Hashing Guide and the Tokenisation and Data Masking Guide. Database products are named alphabetically as examples only.
Key takeaways
- Ask first whether anyone ever needs the original value back. If yes, encrypt (or tokenise); if only equality checks are needed, hash; if people only need to see part of it, mask.
- Encryption moves the problem to the key. Whoever can use the key can read the data, so key custody, separation of duties and access logging decide the real strength.
- Plain hashes of low-entropy data are reversible in practice. Phone numbers, emails and national IDs can be hashed exhaustively; use a keyed hash or a slow password hashing scheme depending on the purpose.
- Dynamic masking is a display control, not a security boundary. Vendor documentation states that stored data is unchanged and that ad hoc queries can infer masked values.
- None of the three makes personal data anonymous on its own. Under GDPR, encrypted, hashed or tokenised data is usually pseudonymised personal data for whoever can link it back.
The short answer
| Property | Encryption | Hashing | Masking |
|---|---|---|---|
| Reversible? | Yes, with the key | Not by design; low-entropy inputs can be guessed | Dynamic: original remains stored. Static: irreversible if done properly |
| Depends on a secret? | Yes, the key | Plain hash: no. Keyed hash (HMAC) or pepper: yes | Dynamic: on access rights. Static: on the masking rules and any seed |
| Output | Ciphertext, usually longer than input unless format-preserving | Fixed-length digest | Same format as input, partly or fully replaced |
| Same input gives same output? | Not with randomised modes; yes with deterministic modes | Yes (unless salted per record) | Depends on the rule (consistent or random) |
| Typical use | Data at rest and in transit that must be read later | Passwords, integrity checks, lookup without storing the value | Support screens, reports, non-production copies |
| Main attack | Key theft or misuse | Brute force, dictionary and precomputed tables | Inference through queries, joins and privileged bypass |
Reversibility and key dependence
Encryption
Encryption is designed to be reversed by an authorised party. Its strength rests on the algorithm, the mode and above all on who can use the key. Randomised authenticated modes such as AES-GCM produce different ciphertext for the same input, which prevents equality matching but also prevents an attacker learning which records share a value. Deterministic encryption allows equality search at the cost of leaking that two records are equal. Format-preserving encryption keeps the shape of the input for legacy schemas. See the Authenticated Encryption and Block Cipher Modes Guide and Format Preserving Encryption.
The design question is where decryption happens and which identity holds that right. Storage or database-level encryption decrypts transparently for any authorised database session, so it protects lost disks and backups but not a compromised application account. Application-layer or field-level encryption keeps ciphertext all the way to the code that needs plaintext. See the Application Layer Encryption Guide.
Hashing
A cryptographic hash maps any input to a fixed-length digest and cannot be inverted mathematically. That does not make the input secret. If an attacker can enumerate likely inputs, they can hash each one and compare. This is trivial for small input spaces: every mobile number in a country, every date of birth, every value of a ten-digit account number. Three variants matter:
- Plain fast hash (SHA-256): right for integrity checks and file fingerprints, wrong for secrets or personal identifiers.
- Keyed hash (HMAC with a secret key): deterministic, so it supports joins and lookups, but cannot be recomputed without the key. This is the usual choice for pseudonymous identifiers and for storing API keys or tokens for lookup.
- Password hashing scheme (Argon2id, scrypt, bcrypt, PBKDF2): deliberately slow and salted per record, so each guess is expensive and identical passwords produce different stored values.
Masking
Masking has two forms with very different properties. Dynamic masking rewrites query results at read time for users without an unmask right; the stored data is unchanged. Microsoft documents that Azure SQL dynamic data masking hides sensitive data in the result set "while the data in the database isn't changed", with administrators and db_owner exempt and other users granted the UNMASK permission at column, table, schema or database level. Oracle documents that Data Redaction is applied at query execution time and leaves stored data unchanged, with full, partial, random, regular expression and nullify redaction types. Static masking produces a changed copy, for example a test database where names, addresses and identifiers have been replaced; if done well, the copy holds no recoverable original values.
Attacks on each technique
| Attack | Technique affected | How it works | Defence |
|---|---|---|---|
| Key theft or misuse | Encryption, keyed hashing | Attacker obtains the key or an identity allowed to call decrypt | Keys in a KMS or HSM, separate decrypt rights from data access, log and alert on key use |
| Offline password cracking (ATT&CK T1110.002) | Hashing | Stolen hashes are guessed offline with dictionaries and rules | Slow salted scheme with a high work factor, plus a pepper held outside the database |
| Precomputed (rainbow) tables | Unsalted hashing | Lookup of precomputed digests for common values | Unique per-record salt makes precomputation useless |
| Enumeration of low-entropy inputs | Plain hashing of identifiers | Hash every possible phone number or ID and compare | Keyed hash with the key held separately |
| Inference through queries | Dynamic masking | Repeated filtered queries reveal the underlying value | Restrict ad hoc query access; do not rely on masking for users who can write SQL |
| Re-identification through joins | Static masking, pseudonymised datasets | Unmasked quasi-identifiers (postcode, birth date, job title) are joined with another dataset | Mask or generalise quasi-identifiers, assess re-identification risk |
| Privileged bypass | Dynamic masking | Exempt roles or users with schema rights see or export real values | Minimise exempt roles; monitor UNMASK and exemption grants |
Oracle's documentation is explicit on two limits of dynamic redaction: it is not intended to stop database users who run ad hoc queries directly, and it places no restriction on the WHERE clause, so a user can infer actual values iteratively while seeing only redacted output. It also warns that redacted values can be written back by applications that perform updates, so redaction suits read-only uses such as call centres, dashboards and reports. Treat any dynamic masking feature the same way unless its own documentation says otherwise.
Encryption failures are usually about keys, not algorithms. In the LastPass Breach 2022, backup decryption keys sat in the same store as the cloud access keys used to copy the backups, so one compromised engineer exposed both the data and the means to decrypt the parts the company could decrypt. Hashing failures are often about not hashing at all: the Firebase Misconfigurations 2024 research found about 19 million passwords stored in plaintext in misconfigured databases.
Use cases: which technique fits
Passwords
Hash, never encrypt. OWASP's Password Storage Cheat Sheet states that passwords should be hashed with modern adaptive algorithms and that encryption is appropriate only in rare cases where the original must be retrieved. Its current minimums are Argon2id with at least 19 MiB of memory, 2 iterations and parallelism 1; scrypt with N=2^17, r=8, p=1 where Argon2id is unavailable; bcrypt with a work factor of at least 10 for legacy systems, with a 72-byte input limit to enforce; and PBKDF2-HMAC-SHA-256 with 600,000 iterations where FIPS-140 compliance is required. NIST SP 800-63B-4 requires passwords to be salted and hashed with a suitable password hashing scheme, salts of at least 32 bits, a cost factor as high as practical and increased over time, and recommends an additional keyed hashing or encryption step with a secret key stored separately from the hashes, ideally in a hardware security module. See the Password Hashing and Key Derivation Guide.
API keys and tokens your service issues
Store a keyed or fast hash of high-entropy tokens for lookup; the token's own entropy makes slow hashing unnecessary, and the plaintext is shown once at creation. Encrypt only credentials your system must present to someone else. See the API Key Management Guide.
Personal data used for analytics
Replace direct identifiers with a keyed hash or a token so records can still be joined, keep the key or mapping in a separate system, and generalise quasi-identifiers. The ICO advises avoiding hashing that uses no additional data such as a salt, pepper or key, and avoiding outdated algorithms such as MD5 and SHA-1, because an attacker can hash guessed inputs and compare. See the Pseudonymisation Techniques Guide.
PII in test and development
Use static masking or synthetic data, not production copies with dynamic masking switched on: developers usually hold the very database rights that bypass dynamic masking. NIST SP 800-188 notes that many tools that only mask personal information lack the functionality needed for proper de-identification, so check quasi-identifiers and free-text fields, not just named columns.
Display to support staff
Dynamic masking or partial redaction (last four digits of a card, first letter of an email) is the right tool, provided those staff reach data through the application and not through ad hoc SQL.
Data that must be read back by systems
Encrypt: payment details that must be charged again, documents, backups, secrets an application must present elsewhere. Where the value is needed only by one service, consider tokenisation so most systems hold only a token. See Client-Side vs Server-Side Encryption.
GDPR status: pseudonymisation, not anonymisation
GDPR Article 4(5) defines pseudonymisation as processing personal data so that it can no longer be attributed to a specific data subject without additional information, provided that information is kept separately and protected by technical and organisational measures. Encryption keys, hash keys and token maps are exactly that additional information. The ICO states that pseudonymised personal data is in scope of data protection law, and that pseudonymised data shared without the additional information may be anonymous in the recipient's hands.
The Court of Justice of the EU took a similar context-based view in case C-413/23 P, EDPS v SRB, judged on 4 September 2025: pseudonymised data is not automatically personal data for every party, and a recipient with no reasonable means of re-identification may not hold personal data, while the controller holding the key still does. The controller's transparency duties, including naming recipients, are assessed from its own perspective at collection. The EDPB's Guidelines 01/2025 on pseudonymisation went to public consultation from 17 January to 14 March 2025; check the EDPB site for the adopted version before relying on specific wording.
| Technique | Usual status for the organisation holding the secret | Can it be anonymous for a recipient? |
|---|---|---|
| Encryption | Personal data (protected; a security measure under Art. 32) | Only if the recipient has no realistic access to the key |
| Keyed hash or token | Pseudonymised personal data | Possibly, if the key or map is not available to it and other data does not identify people |
| Plain hash of an identifier | Pseudonymised at best; weak because it can be recomputed | Rarely, since anyone can hash candidate values |
| Dynamic masking | Personal data, unchanged in storage | No: the data is unchanged |
| Static masking with quasi-identifiers generalised | Can approach anonymisation if re-identification risk is assessed as remote | Depends on a documented re-identification assessment |
See the Anonymisation and Re-identification Risk Guide. This section summarises legal positions and is not legal advice.
Worked scenarios
- Customer login database: Argon2id with OWASP minimum parameters or higher, a per-user salt handled by the library, the scheme and cost stored with each hash, and a pepper held in an HSM or secrets manager. Encryption here would make every password recoverable by anyone who reaches the key.
- Fraud team joining transactions to customers without names: HMAC-SHA-256 of the customer ID with a key in the KMS, accessible only to the pseudonymisation service. A plain SHA-256 of a ten-digit ID could be reversed by enumerating every possible ID.
- Call centre seeing card numbers: dynamic masking showing the last four digits, agents limited to the application, no direct database access, UNMASK held by a small named group.
- Developers needing realistic data: a static masked copy with names, emails, addresses and dates of birth replaced or generalised, free-text notes cleared, and a re-identification check before release.
- Health records stored in a cloud database: application-layer encryption of sensitive fields with envelope encryption, decrypt rights granted only to the service identity that renders records, and masking on top for staff who need partial views. See the Envelope Encryption and KMS Integration Patterns Guide.
Selection table
| Need | Choose | Avoid |
|---|---|---|
| Verify a password | Salted slow password hash plus pepper | Encryption, fast unsalted hash |
| Look up a high-entropy token | Keyed or fast hash of the token | Storing it in plaintext or encrypted for lookup |
| Join records without exposing identity | Keyed hash or token with separated key | Plain hash of low-entropy identifiers |
| Read the value back later | Encryption with managed keys, or tokenisation | Hashing |
| Show part of a value to staff | Dynamic masking or redaction through the application | Relying on it for users with SQL access |
| Realistic non-production data | Static masking or synthetic data | Production copy with dynamic masking |
| Detect tampering with files | Hash (or HMAC or signature where an attacker could replace the hash) | Encryption alone |
Small organisations: use the platform's password hashing library defaults where they meet OWASP minimums, cloud KMS for encryption keys, and static masking scripts for test data. Large organisations: centralise keys and pseudonymisation in a service with its own identity and audit trail, catalogue which fields use which technique, and review re-identification risk for every dataset leaving production.
Where identity fits
Every reversible technique ends in an access decision. The identity allowed to call decrypt, hold the HMAC key, read the token map or hold UNMASK is the real control. These are usually service accounts and workload identities, not people, so give each a single purpose, keep decrypt rights off identities that also hold bulk data export rights, and alert on unusual key use volumes. See the Cryptographic Key Management Guide.
How to implement
- Inventory sensitive fields. For each, record who needs the original value, who needs equality only, and who needs a partial view.
- Assign a technique per field using the selection table, and document the reason.
- Fix passwords first. Move legacy fast or unsalted hashes to a modern scheme by rehashing at next login, or by wrapping the old hash in the new scheme immediately and migrating at login.
- Move keys out of the data plane. Keys, peppers and token maps go into a KMS, HSM or secrets manager with separate access policies and logging.
- Replace production copies in test with static masked or synthetic data, piloted on one system and checked for missed columns and free text.
- Configure dynamic masking in audit with a small user group, confirm application paths work, then extend; keep the previous view available as rollback until reports are verified.
- Review annually work factors, algorithm choices and exempt roles.
Detection and measurement
- Password storage coverage: percentage of accounts hashed with the current scheme and cost.
- Key use anomalies: decrypt or HMAC calls per identity against baseline, with alerts for spikes.
- Exempt and UNMASK grants: count of identities that bypass masking, reviewed quarterly against need.
- Non-production exposure: number of non-production datastores containing unmasked production personal data (target zero), found by data discovery scans.
- Weak hash findings: code scan or data discovery hits for MD5, SHA-1 or unsalted digests used on secrets or identifiers.
Common failure patterns
- Encrypting passwords: anyone with the key, including an insider or an attacker with application access, recovers every password.
- Calling a plain hash "anonymised": hashing an email or phone number with SHA-256 and sharing it as anonymous data, when anyone can hash candidate values.
- Keys beside the data: encryption keys or peppers in the same database, repository or vault as the data they protect.
- Dynamic masking for developers: giving engineers production access with masking switched on, when their rights let them infer or bypass it.
- Masking named columns only: leaving free-text notes, logs and attachments that contain the same personal data.
- Never raising work factors: a bcrypt or PBKDF2 cost chosen years ago and never revisited.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SC-12 Cryptographic Key Establishment and Management; SC-13 Cryptographic Protection | Key custody and approved cryptography |
| NIST SP 800-53 Rev. 5 | SC-28 Protection of Information at Rest | Encryption of stored data |
| NIST SP 800-53 Rev. 5 | IA-5(1) Password-based Authentication | Salted, hashed password storage |
| NIST SP 800-53 Rev. 5 | SI-19 De-identification | Masking and pseudonymisation of datasets |
| NIST CSF 2.0 | PR.DS-01 | Data at rest protected |
| ISO/IEC 27001:2022 Annex A | 8.11 Data masking; 8.24 Use of cryptography | Masking policy and cryptographic controls |
| GDPR | Art. 4(5); Art. 32 | Pseudonymisation definition; encryption and pseudonymisation as security measures |
| MITRE ATT&CK v20 | T1110.002 Password Cracking | Offline attack that slow salted hashing resists |
Practitioner checklist
- Record for every sensitive field whether originals, equality or partial views are needed.
- Store passwords with Argon2id, scrypt, bcrypt or PBKDF2 at or above OWASP minimums, with per-record salts.
- Keep peppers, HMAC keys, encryption keys and token maps outside the data store, in a KMS, HSM or vault.
- Replace plain hashes of identifiers with keyed hashes or tokens.
- Separate decrypt and unmask rights from bulk data access.
- Use static masking or synthetic data for non-production; never production copies.
- Restrict ad hoc SQL for users who should only see masked values.
- Treat encrypted, hashed and tokenised personal data as personal data unless a documented assessment says otherwise.
- Review work factors, exempt roles and key access logs at least annually.
Standards and references
- NIST: SP 800-63B-4 Authentication and Authenticator Management
- NIST: SP 800-188 De-Identifying Government Datasets: Techniques and Governance
- OWASP: Password Storage Cheat Sheet
- GDPR: Article 4 Definitions
- ICO: Pseudonymisation guidance
- EDPB: Guidelines 01/2025 on pseudonymisation
- Microsoft Learn: Dynamic data masking
- Oracle: Introduction to Oracle Data Redaction
Related NHI Mgmt Group resources: Hashing Guide · Encryption Guide · Tokenisation and Data Masking Guide · Pseudonymisation Techniques Guide · Data Masking and Tokenisation Buyer's Guide. This guide summarises data protection law positions and is not legal advice.