直接访问数据库的多用户应用：私钥存储更优方案技术问询

Great question—this is a common pain point when dealing with user-specific key pairs in systems where database exposure is a real risk. Let’s break down some better alternatives, along with their tradeoffs and ideal use cases:

1. Hardware Security Module (HSM) Key Custodianship #

Instead of storing encrypted private keys in the database, keep the private keys entirely within an HSM. Your database only needs to store the user’s public key and a reference ID pointing to the corresponding private key in the HSM.

• How it works: After user authentication, your application sends requests to the HSM to perform operations (like signing or decrypting) using the user’s private key. The HSM never exports the private key outside its secure hardware boundary—it validates the user’s authenticated session (via tokens or role-based permissions) before executing the operation.
• Advantages: Private keys never leave a tamper-resistant, certified hardware environment. Even if an attacker exfiltrates your entire database, they can’t access the actual private keys. HSMs also provide robust audit logs for key usage.
• Tradeoffs: Higher upfront and operational costs. Best suited for high-security use cases (e.g., financial services, healthcare) where the risk of private key compromise is catastrophic.

2. Envelope Encryption with a Key Management Service (KMS) #

This approach adds a layer of abstraction between your user’s private key and the encryption mechanism:

• How it works:
  1. Generate a unique Data Encryption Key (DEK) for each user.
  2. Encrypt the user’s private key with the DEK, then store the encrypted private key in your database.
  3. Encrypt the DEK itself using a centralized Key Encryption Key (KEK) managed by a KMS, and store the encrypted DEK alongside the private key (or let the KMS track it).
  4. After user authentication, your application requests the KMS to decrypt the DEK (validating the user’s permissions via their auth token). Use the decrypted DEK to unlock the private key temporarily in memory.
• Advantages: If the database is breached, attackers only get encrypted private keys and encrypted DEKs—they can’t decrypt either without access to the KMS. You also avoid re-encrypting private keys when users change their passwords; instead, you just adjust the KMS permissions for that user’s DEK.
• Tradeoffs: Relies on the KMS’s availability and security. Costs are lower than HSMs, making this a solid middle ground for most enterprise applications.

3. 2FA-Enhanced Key Unlocking #

Instead of relying solely on a password-derived key, combine it with a second authentication factor to derive the encryption key for the private key:

• How it works: Derive two separate sub-keys—one from the user’s password (via a strong KDF like Argon2) and another from their 2FA factor (e.g., a TOTP code, hardware token seed). Combine these sub-keys (using a secure hash or XOR) to create the final encryption key for the private key.
• Advantages: Even if an attacker gets the encrypted private key and the user’s password (e.g., via a credential leak), they can’t decrypt the private key without the 2FA factor. This drastically reduces the risk of offline brute-force attacks.
• Tradeoffs: Adds friction to the user experience (requires enabling 2FA). You’ll need a robust recovery process for users who lose their 2FA device (e.g., backup recovery codes stored securely).

4. Shamir’s Secret Sharing with Zero-Knowledge Proofs (ZKPs) #

Split the user’s private key into multiple shards, distributing control between the user and your system:

• How it works:
  1. Split the private key into N shards using Shamir’s Secret Sharing, where M shards are required to reconstruct the key (e.g., 2 out of 3).
  2. Store some shards in your database, and have the user store the remaining shards locally (e.g., in their device’s secure enclave or a password manager).
  3. When the user authenticates, they provide their shard(s). Use a zero-knowledge proof to verify the user holds a valid shard without exposing its content, then combine it with the database’s shards to reconstruct the private key in memory.
• Advantages: A database breach alone can’t yield the full private key—attackers would also need to steal the user’s local shards. ZKPs ensure the verification process doesn’t leak any sensitive shard data.
• Tradeoffs: High implementation complexity (requires deep cryptography expertise). User experience needs careful design for shard backup and recovery.

Final Notes #

The "best" solution depends on your specific security requirements, budget, and user experience constraints. For most applications, KMS-backed envelope encryption strikes the best balance between security, cost, and usability. For ultra-sensitive use cases, an HSM is the gold standard.

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