未绑定外部通讯方式、仅用户名标识的账号密码重置方案问询

Hey there, let's walk through these two password reset scenarios you're tackling—they're tricky edge cases where you've got to balance security, usability, and the constraints you're working with. Here's what I've seen work in production systems:

When an account has no linked email, phone, or other external channels, you need to rely on pre-existing account data or trusted verification workflows:

• Pre-Registered, High-Entropy Security Questions (with Guardrails)
  Skip the generic "mother's maiden name" questions—those are easy to brute-force or find online. Instead, let users set custom, hyper-specific questions during registration (e.g., "What was the license plate number of your first motorcycle?" or "What's the name of the first school you attended?") that only they'd know. Pair this with:

  • Strict rate limiting on reset attempts to block automated brute-force attacks.
  • A requirement to provide one additional account detail (like the approximate registration date, or the last 4 characters of a past password—never store plaintext passwords, so compare a hash of the user's input to your stored password history hashes).

• Manual Identity Verification via Trusted Support
  Build a workflow where users submit a reset request, then provide pre-collected identity data you stored securely during registration (e.g., a partial government ID number, billing address, or unique account-specific details like the first item they purchased). Your support team verifies these details against your encrypted records, then initiates a password reset. To mitigate internal risk:

  • Limit reset permissions to a small, trained support group.
  • Require dual approval for high-risk accounts (like those with payment or sensitive personal info).
  • Log every reset action for full audit trails.

• Device-Bound Recovery Tokens
  If users log in via desktop apps or mobile devices, generate an encrypted recovery token during their first login and store it locally on their device (e.g., in a secure keychain or encrypted storage). When a reset is requested, prompt the user to access the token from their trusted device, then combine that with a username match and a quick verification question. This ties the reset to a device the user already controls, adding an extra layer of security that's hard for attackers to replicate.

Since you're only using usernames as the unique identifier, you can't rely on external channels to confirm ownership. Here are the most practical, secure options:

• Multi-Factor Credential Verification
  Ask the user to provide a combination of non-public account details that only the legitimate owner would know. For example:

  • The approximate date they registered the account.
  • The last three devices they logged in from (e.g., "iPhone 13" or "Windows Laptop").
  • Specific details about past account activity (e.g., "What was the amount of your second transaction?" for e-commerce platforms).
    Require at least 2-3 of these to match your stored data before allowing a reset. Pair this with strict rate limiting to prevent attackers from guessing details over time.

• Time-Limited Lock + Manual Review
  When a user requests a reset, immediately lock their account for a fixed window (e.g., 24 hours) to block unauthorized access while verification is underway. Then prompt the user to submit identity verification materials (like the pre-collected data mentioned earlier) to your support team. Once verified, unlock the account and let the user set a new password directly (or send a temporary password via a secure in-app prompt if applicable). The lock buys you time to review without exposing the account to risk.

• Pre-Generated Offline Recovery Keys
  During registration, generate a unique, long recovery key (16+ random alphanumeric characters, or a mnemonic phrase like those used for crypto wallets) and ask the user to download, print, or write it down securely. When resetting, the user must enter both their username and this recovery key. This is extremely secure, but you need to clearly emphasize to users that losing the key means they can't recover their account—so consider adding an option to regenerate the key later (only when the user is logged in with their current password).

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