Should You Hash OTPs in Your Database?
Yes, always — and bcrypt or scrypt, not SHA-256. Why hashing OTPs matters even though they're short-lived, and concrete code patterns.
StartMessaging Team
Engineering
Even ephemeral codes deserve hashing. A database leak with hashed OTPs gives you breathing room; with plaintext OTPs every active session is at immediate risk.
Why Hash an Ephemeral Code?
- Database leak protection during the validity window.
- DPDP / PCI-DSS “reasonable security” obligations.
- Defence-in-depth.
Which Algorithm
- Bcrypt cost 10–12.
- Scrypt or Argon2 if you have Argon2 native bindings.
- Never SHA-256 / MD5 / SHA-1.
Cost Factor
Bcrypt cost 10 is ~70ms on modern hardware. The user can’t feel it; the attacker really can.
If You Use a Managed Provider
StartMessaging hashes the OTP server-side with bcrypt cost 12 by default. You never see plaintext on your servers; nothing to hash on your side.
FAQ
Even with managed provider, hash any locally-stored OTP-adjacent data (PINs, recovery codes, etc.).
Related Articles
Database schema patterns for storing OTP request metadata: required columns, indexes, retention, hashing, and the columns you should never have.
Trade-offs between Redis and SQL for OTP request data. Latency, durability, audit, retention, and a recommended hybrid pattern that uses both.
Learn how to secure OTP systems with bcrypt hashing, rate limiting, expiry windows, attempt limits, HTTPS enforcement, and idempotency keys.
Ready to Send OTPs?
Integrate StartMessaging in 5 minutes. No DLT registration required.