参考 - 密码验证 [英] Reference - Password Validation

问题描述

很多时候，问题(尤其是那些标记为

为什么密码验证规则不好?

我们自己的 Jeff Atwood(_{(GitHub 上的一个开源项目).它经过调整以支持 .netangularjscc#c++gojavajavascriptobjective-cocamlphppythonrestrubyrustscala}

---

做错了

然而，我理解每个人都有不同的要求，而且有时人们想以错误的方式做事.对于那些符合此标准的人(或者没有选择并已将本节以上的所有内容以及更多内容提交给您的经理，但他们拒绝更新他们的方法)至少允许使用 Unicode 字符.当您将密码字符限制为一组特定的字符时(即确保存在小写 ASCII 字符 az 或指定用户可以或不能输入的字符 !@#$%^&*())，你只是自找麻烦！

P.S.永远不要相信客户端验证，因为它很容易被禁用.这意味着对于那些尝试使用 javascript 停止.有关更多信息，请参阅 JavaScript:客户端与服务器端验证信息.

以下正则表达式模式并不适用于所有编程语言，但适用于许多主要的编程语言(java.netphpperlruby).请注意，以下正则表达式可能不适用于您的语言(甚至语言版本)，您可能需要使用替代方案(即 python:参见 Python 正则表达式匹配Unicode 属性).一些编程语言甚至有更好的方法来检查这类事情(即使用 密码验证插件 mysql) 而不是重新发明轮子.使用 node.js 以下是如果使用 XRegExp 插件 或 Javascript + Unicode 正则表达式.

_{如果您需要防止输入控制字符，您可以使用模式[^P{C}s]在正则表达式匹配发生时提示用户.这将只匹配不是空白字符的控制字符 - 即水平制表符、换行符、垂直制表符.}

以下正则表达式确保 8 个字符以上的密码中至少存在一个小写、大写、数字和符号:

^(?=P{Ll}*p{Ll})(?=P{Lu}*p{Lu})(?=P{N}*p{N})(?=[p{L}p{N}]*[^p{L}p{N}])[sS]{8,}$

• ^ 在行首断言位置.
• (?=P{Ll}*p{Ll}) 确保至少存在一个小写字母(在任何脚本中).
• (?=P{Lu}*p{Lu}) 确保至少存在一个大写字母(在任何脚本中).
• (?=P{N}*p{N}) 确保至少存在一个数字字符(在任何脚本中).
• (?=[p{L}p{N}]*[^p{L}p{N}]) 确保任何字符(在任何script) 不是字母或数字.
• [sS]{8,} 匹配任意字符 8 次或更多次.
• $ 断言行尾位置.

请自行决定使用上述正则表达式.您已被警告！

Quite often, questions (especially those tagged regex) ask for ways to validate passwords. It seems users typically seek password validation methods that consist of ensuring a password contains specific characters, matches a specific pattern and/or obeys a minimum character count. This post is meant to help users find appropriate methods for password validation without greatly decreasing security.

So the question is: How should one properly validate passwords?

解决方案

Why password validation rules are bad?

Our very own Jeff Atwood (blogger of Coding Horror and co-founder of Stack Overflow and Stack Exchange) wrote a blog about password rules back in March of 2017 titled Password Rules are Bullshit. If you haven't read this post, I would urge you to do so as it greatly mirrors the intent of this post.

If you have never heard of NIST (National Institute of Standards and Technology), then you're likely not using correct cybersecurity methods for your projects. In that case please take a look at their Digital Identity Guidelines. You should also stay up to date on best practices for cybersecurity. NIST Special Publication 800-63B (Revision 3) mentions the following about password rules:

Verifiers SHOULD NOT impose other composition rules (e.g. requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets.

Even Mozilla's documentation on Form data validation pokes fun at password rules (page archive here):

"Your password needs to be between 8 and 30 characters long, and contain one uppercase letter, one symbol, and a number" (seriously?)

What happens if you impose composition rules for your passwords? You're limiting the number of potential passwords and removing password permutations that don't match your rules. This allows hackers to ensure their attacks do the same! "Ya but there's like a quadrillion (1,000,000,000,000,000 or 1x10¹⁵) password permutations": 25-GPU cluster cracks every standard Windows password in <6 hours (95⁸ = 6,634,204,312,890,625 ~ 6.6x10¹⁵ passwords).

_{This StackExchange Security post extends the XKCD comic above.}

How do I validate passwords?

1. Don't create your own authentication

Stop requiring passwords altogether, and let people log in with Google, Facebook, Twitter, Yahoo, or any other valid form of Internet driver's license that you're comfortable with. The best password is one you don't have to store.

_{Source: Your Password is Too Damn Short by Jeff Atwood.}

2. Creating your own authentication

If you really must create your own authentication methods, at least follow proven cybersecurity methods. The following two sections (2.1 and 2.2) are taken from the current NIST publication, section 5.1.1.2 Memorized Secret Verifiers.

2.1. Follow PROVEN cybersecurity methods

NIST states that you SHOULD:

• Require subscriber-chosen memorized secrets to be at least 8 characters in length.
  • Jeff Atwood proposes passwords should be a minimum of 10 characters for normal users and a minimum of 15 characters for users with higher privileges (i.e. admins and moderators).
• Permit subscriber-chosen memorized secrets up to 64 characters or more in length.
  • Ideally, you shouldn't even put an upper limit on this.
• Allow all printing ASCII (including the space character) and Unicode.
  • For purposes of length requirements, each Unicode code point SHALL be counted as a single character.
• Compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example:
  • Passwords obtained from previous breach corpuses.
  • Dictionary words.
  • Repetitive or sequential characters (e.g. aaaaaa, 1234abcd)
  • Context-specific words, such as the name of the service, the username, and derivatives thereof.
• Offer guidance to the subscriber, such as a password-strength meter.
• Implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber's account (see Rate Limiting (Throttling)).
• Force a change if there is evidence of compromise of the authenticator.
• Permit claimants to use paste functionality when entering a memorized secret (facilitates the use of password managers, which typically increase the likelihood that users will choose stronger memorized secrets).

2.2. DO NOT use any of the methods in this section!

The same publication also states that you SHOULD NOT:

• Truncate the secret.
• Permit the subscriber to store a hint that is accessible to an unauthenticated claimant.
• Prompt subscribers to use specific types of information (e.g. "What was the name of your first pet?") when choosing memorized secrets.
• Impose other composition rules (e.g. requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets.
• Require memorized secrets to be changed arbitrarily (e.g. periodically).

There are a plethora of websites out there explaining how to create "proper" password validation forms: Majority of these are outdated and should not be used.

3. Using Password Entropy

Before you continue to read this section, please note that this section's intent is not to give you the tools necessary to roll out your own security scheme, but instead to give you information about how current security methods validate passwords. If you're considering creating your own security scheme, you should really think thrice and read this article from StackExchange's Security community.

3.1. Overview of Password Entropy

At the most basic level, password entropy can be calculated using the following formula:

In the above formula:

• represents password entropy
• is the number of characters in the pool of unique characters
• is the number of characters in the password

This means that represents the number of possible passwords; or, in terms of entropy, the number of attempts required to exhaust all possibilities.

Unfortunately, what this formula doesn't consider are things such as:

• Generic passwords: i.e. Password1, admin
• Names: i.e. John, Mary
• Commonly used words: i.e. In the English language the, I
• Reversed/Inverted words: i.e. drowssap (password backwards)
• Letter substitution (aka leet): i.e. P@$$w0rd

Adding logic for these additional considerations presents a large challenge. See 3.2 for existing packages that you can add to your projects.

3.2. Existing Password Entropy projects

At the time of writing this, the best known existing library for estimating password strength is zxcvbn by Dropbox (an open-source project on GitHub). It's been adapted to support .netangularjscc#c++gojavajavascriptobjective-cocamlphppythonrestrubyrustscala

---

Doing it the wrong way

I understand, however, that everyone has different requirements and that sometimes people want to do things the wrong way. For those of you that fit this criterion (or don't have a choice and have presented everything above this section and more to your manager but they refuse to update their methods) at least allow Unicode characters. The moment you limit the password characters to a specific set of characters (i.e. ensuring a lowercase ASCII character exists a-z or specifying characters that the user can or cannot enter !@#$%^&*()), you're just asking for trouble!

P.S. Never trust client-side validation as it can very easily be disabled. That means for those of you trying to validate passwords using javascript STOP. See JavaScript: client-side vs. server-side validation for more information.

The following regular expression pattern does not work in all programming languages, but it does in many of the major programming languages (java.netphpperlruby). Please note that the following regex may not work in your language (or even language version) and you may need to use alternatives (i.e. python: see Python regex matching Unicode properties). Some programming languages even have better methods to check this sort of thing (i.e. using the Password Validation Plugin for mysql) instead of reinventing the wheel. Using node.js the following is valid if using the XRegExp addon or some other conversion tool for Unicode classes as discussed in Javascript + Unicode regexes.

_{If you need to prevent control characters from being entered, you can prompt the user when a regex match occurs using the pattern [^P{C}s]. This will ONLY match control characters that are not also whitespace characters - i.e. horizontal tab, line feed, vertical tab.}

The following regex ensures at least one lowercase, uppercase, number, and symbol exist in a 8+ character length password:

^(?=P{Ll}*p{Ll})(?=P{Lu}*p{Lu})(?=P{N}*p{N})(?=[p{L}p{N}]*[^p{L}p{N}])[sS]{8,}$

• ^ Assert position at the start of the line.
• (?=P{Ll}*p{Ll}) Ensure at least one lowercase letter (in any script) exists.
• (?=P{Lu}*p{Lu}) Ensure at least one uppercase letter (in any script) exists.
• (?=P{N}*p{N}) Ensure at least one number character (in any script) exists.
• (?=[p{L}p{N}]*[^p{L}p{N}]) Ensure at least one of any character (in any script) that isn't a letter or digit exists.
• [sS]{8,} Matches any character 8 or more times.
• $ Assert position at the end of the line.

Please use the above regular expression at your own discretion. You have been warned!

这篇关于参考 - 密码验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！