密码安全
Help your users to protect their password security
如果密码更难被猜到或通过暴力破解,它就更安全。理论上,密码越长就越难猜。同时,如果密码使用的字符集合更多(例如数字、大小写字母和符号),也会更难猜。
🌐 A password is more secure if it is harder to guess or brute-force. In theory, a password is harder to guess if it is longer. It is also harder to guess if it uses a larger set of characters (for example, digits, lowercase and uppercase letters, and symbols).
这张表显示了访问用户账户所需尝试的_最少_猜测次数:
🌐 This table shows the minimum number of guesses that need to be tried to access a user's account:
| 所需字符 | 长度 | 猜测次数 |
|---|---|---|
| 仅数字 | 8 | ~ 227 |
| 数字和字母 | 8 | ~ 241 |
| 数字、大小写字母 | 8 | ~ 248 |
| 数字、大小写字母、符号 | 8 | ~ 252 |
不过实际上,密码并不总是随机生成的。它们经常包含名称、单词、日期和常用短语的变体。恶意人员可以利用这些特点用更少的尝试就猜到密码。
🌐 In reality though, passwords are not always generated at random. They often contain variations of names, words, dates, and common phrases. Malicious actors can use these properties to guess a password in fewer attempts.
已经有数亿个(而且还在增长!)已知的密码存在。恶意行为者可以利用这些泄露的密码列表自动尝试登录(称为凭证填充),从而窃取或访问敏感的用户数据。
🌐 There are hundreds of millions (and growing!) known passwords out there. Malicious actors can use these lists of leaked passwords to automate login attempts (known as credential stuffing) and steal or access sensitive user data.
密码强度和被泄露密码保护 #
🌐 Password strength and leaked password protection
为了帮助保护你的用户,Supabase Auth 允许你对项目中使用的密码强度进行精细控制。你可以在项目的认证设置中进行配置:
🌐 To help protect your users, Supabase Auth allows you fine-grained control over the strength of the passwords used on your project. You can configure these in your project's Auth settings:
- 设置一个较大的最小密码长度。不建议使用少于8个字符的密码。
- 设置用户密码中必须至少出现一次的字符。使用最强选项,要求包含数字、小写字母、大写字母和符号。允许的符号是:
!@#$%^&*()_+-=[]{};'\:"|<>?,./`~ - 防止使用已泄露的密码。Supabase Auth 使用开源的 HaveIBeenPwned.org Pwned Passwords API 来拒绝那些已泄露并被恶意者知晓的密码。
泄露密码保护仅在专业版及以上计划中可用。
🌐 Leaked password protection is available on the Pro Plan and above.
更改密码时需要重新认证 #
🌐 Require reauthentication when changing password
用户需要最近登录过,才能在不需要重新认证的情况下更改密码。(如果会话是在过去24小时内创建的,则用户被认为是最近登录过的。)如果禁用此功能,用户可以随时更改密码。
🌐 Users will need to be recently logged in to change their password without requiring reauthentication. (A user is considered recently logged in if the session was created within the last 24 hours.) If disabled, a user can change their password at any time.
启用后,会向用户发送一个 nonce,并且在密码更改之前必须验证这个随机数。这可以通过调用 reauthenticate() API 来触发。
🌐 When enabled, a nonce will be sent to the user and this nonce must be validated before the a password change can occur. This can be triggered with the reauthenticate() API call.
1const { error } = await supabase.auth.reauthenticate()2...3// send the nonce provided by the user with the password change4const { data, error } = await supabase.auth.updateUser({5 email: 'user@email.com',6 nonce: `${nonce}`,7 password: "new_super_strong_password"8})更改密码时需要当前密码 #
🌐 Require current password when changing password
在用户尝试更改密码时,强制要求输入当前密码。启用后,密码更改请求会在更新用户密码之前验证当前密码是否正确。
🌐 Enforce that users supply their current password when trying to change the password. When enabled, the password change request will validate that the current password is correct before updating the user's password.
1const { data, error } = await supabase.auth.updateUser({2 email: 'user@email.com',3 current_password: "correct_current_password",4 password: "new_super_strong_password"5})额外建议 #
🌐 Additional recommendations
除了选择合适的密码强度设置并防止使用泄露的密码外,还可以考虑让你的用户:
🌐 In addition to choosing suitable password strength settings and preventing the use of leaked passwords, consider asking your users to:
- 使用密码管理器来存储和生成密码。
- 别在不同网站和应用上重复使用密码。
- 尽量不要在密码中使用个人信息。
- 使用多因素认证。
常见问题 #
🌐 Frequently asked questions
密码是怎么存储的? #
🌐 How are passwords stored?
Supabase Auth 使用 bcrypt,这是一种强大的密码哈希函数,用来存储用户密码的哈希值。只会存储哈希后的密码,你不能用密码哈希来冒充用户。每个哈希都会配上随机生成的 salt 参数,以增加安全性。
🌐 Supabase Auth uses bcrypt, a strong password hashing function, to store hashes of users' passwords. Only hashed passwords are stored. You cannot impersonate a user with the password hash. Each hash is accompanied by a randomly generated salt parameter for extra security.
哈希值存储在 auth.users 表的 encrypted_password 列中。这个列名有点误导(加密哈希并不是加密),但是为了向后兼容而保留着。
🌐 The hash is stored in the encrypted_password column of the auth.users table. The column's name is a misnomer (cryptographic hashing is not encryption), but is kept for backward compatibility.
加强密码要求会如何影响现有用户? #
🌐 How will strengthened password requirements affect current users?
现有用户即使密码不符合新的、强化的密码要求,也仍然可以使用当前密码登录。不过,如果他们的密码达不到这些更新的标准,在signInWithPassword过程中会遇到WeakPasswordError,说明为什么密码被认为不够安全。这一变化同样适用于新用户和正在更改密码的现有用户,确保每个人都遵守加强后的安全标准。
🌐 Existing users can still sign in with their current password even if it doesn't meet the new, strengthened password requirements. However, if their password falls short of these updated standards, they will encounter a WeakPasswordError during the signInWithPassword process, explaining why it's considered weak. This change is also applicable to new users and existing users changing their passwords, ensuring everyone adheres to the enhanced security standards.