Understanding the Dilemma
The recent breach at Times Car, where 6.6 million user accounts were compromised, highlights a critical question for data governance teams: should you hash passwords or encrypt them? The company's vague statement that passwords were stored in "a form that cannot be restored" suggests hashing, yet it underscores a common confusion between these two distinct methods.
Your choice between hashing and encryption isn't trivial. It affects what an attacker can do with stolen data, your breach response strategy, and your compliance with Article 32 GDPR requirements for "appropriate technical and organisational measures."
Why One-Way Hashing is Preferred
Most security frameworks advocate for one-way hashing of passwords. The logic is simple: you don't need to see a user's actual password, just verify it. Hashing with functions like bcrypt or Argon2 creates a fixed-length string that can't be reversed. If an attacker steals your database, they get unusable data. While they can try to guess passwords, a properly configured work factor makes this impractical.
The principle of least privilege supports hashing: don't store what you don't need. If your system never requires the plaintext password, storing it in any recoverable form is an unnecessary risk.
Hashing also streamlines breach response. With properly hashed passwords using unique salts and work factors, you can avoid a mass password reset, which erodes user trust and overwhelms support. Instead, notify users, suggest precautionary changes, and monitor for unusual activity.
When Reversible Encryption is Necessary
However, encryption is sometimes necessary. Confusing these methods can lead to compliance issues.
Consider legacy systems that authenticate using stored credentials, multi-tenant platforms needing to pass tokens, or credential vaults where recovery is essential. In these cases, reversible access to the secret is required.
Encryption allows you to retrieve plaintext when authorized. Use strong algorithms like AES-256, secure keys in a hardware security module or key management service, and enforce strict access controls.
Encryption is also crucial for specific compliance needs. If you must prove to a supervisory authority that you can delete personal data on request, encrypted data with cryptographic erasure (destroying the key) is a defensible measure. Hashed data can't be "deleted" in the same way.
Practical Applications
In practice, data governance teams use both methods based on data type and use case.
Authentication passwords should always be hashed. There's no need to recover a user's login password, and the security benefits of irreversibility are clear.
API keys, service credentials, and integration tokens are often encrypted because systems need to use them programmatically. You can't hash a credential you need to send to a third-party service.
The Times Car incident shows why clarity is crucial. Their statement about passwords being stored in a "form that cannot be restored" suggests hashing, but raises questions about their actual implementation. Did they use a modern hashing algorithm with proper work factors? Are salts unique per user? Can they prove this to their supervisory authority?
If you can't clearly explain your protection method and rationale, you likely haven't implemented it correctly.
Conclusion
Hash authentication passwords. Encrypt credentials you need to use.
Confusion between these methods poses real compliance risks. Article 32 GDPR requires "appropriate technical and organisational measures" based on current standards and risks. A supervisory authority will want to know your breach response details, your chosen approach, and its alignment with standards.
Document your decision framework. Your data classification policy should specify which protection applies to each data type, and your technical teams should explain the implementation details. When you say passwords are hashed, know the algorithm, work factor, and salting approach. When you say credentials are encrypted, know the key management architecture and access controls.
Avoid vague language in breach notifications. "A form that cannot be restored" is unhelpful. If passwords were hashed with bcrypt at work factor 12, say so. Precision in public statements reflects precision in your security architecture, which is vital for maintaining trust with affected users.
The choice between hashing and encryption becomes clear once you ask: do you need to see the plaintext again? Ensure your teams understand the distinction and can defend their implementation when questioned by a supervisory authority.
