密码盐存储安全咨询：同表存储是否存在风险？

Great question—your concern about salt storage is totally valid, and it’s smart to think beyond the default approach when running a production system. Let’s break this down and look at practical, secure options that fit your three-tier setup.

First, a quick reality check: Storing salts in the same table as credentials is standard because salts aren’t meant to be secret. Their primary job is to neutralize rainbow table attacks, not to hide from an attacker who already has full access to your database. That said, if you want to raise the attack bar even higher (especially for scenarios where your main auth database is compromised), there are solid strategies to separate salt storage.

Recommended Strategies for Your Three-Tier System #

1. Separate Key-Value Store or Secondary Database #

Deploy a dedicated, isolated storage service (like Redis, Memcached, or a separate SQL database instance) exclusively for storing user salts mapped to their IDs. Here’s how it fits your architecture:

• Your application tier’s authentication service first fetches the salt from this isolated store using the user’s ID.
• It then retrieves the hashed password from your main auth database, combines the salt with the user’s input password, rehashes it, and compares against the stored hash.
• Key benefits: Even if an attacker gains access to your main auth table, they won’t have the salts needed to crack the hashes. The isolated store can have stricter access controls (e.g., only your auth service has network access to it).
• Pro tip: Use commands like GET salt:{user_id} (for Redis) to fetch salts efficiently, and ensure this service has high availability with failover to avoid login outages.

2. Use a Centralized Key Management Service (KMS) #

Integrate a KMS (either self-hosted or a managed service) to store your salts. For per-user salts:

• Map each user’s ID to their unique salt in the KMS.
• Your application tier requests the salt via the KMS API during authentication, then proceeds with hash verification as usual.
• Key benefits: KMS platforms offer robust access controls, audit logging, and encryption at rest. Even if your main database is breached, an attacker would need separate access to the KMS to get the salts—adding a critical extra layer.
• Note: Ensure your application’s KMS credentials are stored securely (e.g., in environment variables, not hard-coded) and follow least-privilege access rules.

3. Pepper + Salt Hybrid Approach #

Combine per-user salts (stored in your main auth table) with a global "pepper"—a secret value stored only in your application tier’s secure configuration (or KMS). Here’s how it works:

• When hashing a password: hash(pepper + salt + user_password)
• During verification: Fetch the salt from the database, pull the pepper from your secure config, combine with the user’s input, rehash, and compare.
• Key benefits: This balances security and usability. If your main database is compromised, attackers can’t crack the hashes without the pepper (which isn’t stored in the database at all). You don’t need a separate storage service for per-user data, making maintenance simpler.

Critical Best Practices to Follow #

• Never reuse salts: Each user must have a unique, cryptographically random salt. Reusing salts defeats their purpose.
• Encrypt in-transit: Ensure all communication between your application tier and salt storage services uses TLS to prevent man-in-the-middle attacks.
• Backup safely: Salts are essential for password verification—lose them, and you can’t authenticate users. Store backups separately from your main database backups, and encrypt them.
• Avoid over-engineering: Balance security with availability. For example, if your isolated salt store goes down, users can’t log in—so implement failover and monitoring.

内容的提问来源于stack exchange，提问作者Marcel Marino