设计加密用户资料系统：实现安全的短信账户恢复功能

Alright, let's break down a secure, practical implementation for your encrypted user profile system that works seamlessly with all three authentication paths you've outlined — while keeping user data locked down tight.

核心密钥体系基础 #

First off, you'll need a single User Master Key (UMK) — this is the symmetric key that does the actual encrypting and decrypting of all user profile data. The critical rule here: never store the plaintext UMK on your servers. Instead, you'll create encrypted copies of the UMK, each tied to one of your authentication methods.

绑定三种访问方式到UMK #

Each authentication flow will let users derive a key that can unlock one of these encrypted UMK copies. Here's how each flow works in practice:

1. 账户密码验证 #

• When a user creates an account, take their password and run it through a strong key derivation function (KDF) like Argon2id (preferred) or PBKDF2-HMAC-SHA256. Use a unique per-user salt and aggressive parameters (e.g., 100,000+ iterations for PBKDF2, or memory/cpu costs tailored to your server capacity for Argon2). This generates a Password-Wrapped Key (PWK).
• Use AES-256-GCM (which provides both confidentiality and integrity) to encrypt the UMK with PWK, storing the result as EncryptedUMK_PW on your server.
• When the user logs in, re-derive PWK using the same salt and KDF, then decrypt EncryptedUMK_PW to get the plaintext UMK. You can then use this UMK to access their encrypted profile data.

2. 离线备份码重置 #

• Generate a high-entropy offline backup code when the user sets up their account (think 192 bits of randomness, formatted as 6 groups of 4 alphanumeric characters for readability).
• Treat this backup code exactly like a password: run it through the same KDF as above, but use a different unique salt (separate from the password salt) to generate a Backup-Wrapped Key (BWK).
• Encrypt the UMK with BWK, storing the result as EncryptedUMK_BW on your server.
• When the user needs to reset their password via backup code, have them input the code, derive BWK, decrypt EncryptedUMK_BW to get the UMK, then let them set a new password. Afterward, re-derive PWK from the new password and update EncryptedUMK_PW with the fresh encryption.

3. 短信验证码重置 #

Since you've confirmed the SMS channel and receiving device are secure, here's a robust, low-risk flow:

• When the user initiates a password reset via SMS, your server generates a short-lived Temp Reset Key (TRK) (256-bit random, valid for 15 minutes max).
• Encrypt the UMK with TRK to create EncryptedUMK_TR, and store this temporarily on your server.
• Send a 6-digit SMS code to the user's verified phone number. Store a hashed version of this code (with a unique salt) alongside EncryptedUMK_TR — never store the plaintext code.
• When the user inputs the SMS code, verify its hash matches the stored value. Then, derive a temporary unlock key from the SMS code (you can use a lightweight KDF here, since the code is short-lived) to decrypt TRK. Once you have TRK, decrypt EncryptedUMK_TR to get the UMK, then let the user set a new password and update EncryptedUMK_PW.
• Critical cleanup: Delete EncryptedUMK_TR and the SMS code hash immediately after the reset completes or the timeout expires.

非 negotiable 安全细节 #

• Always use authenticated encryption (like AES-GCM) for all encrypted data — this prevents tampering and ensures you detect if data has been altered.
• Rotate salts for every KDF operation (password, backup code, SMS code) to eliminate rainbow table attack risks.
• Never log any plaintext keys, passwords, or backup codes — even for debugging.
• For the backup code, encourage users to store it offline (not in notes apps or emails) to reduce exposure risk.

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