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

问题描述

问题(通常是带有问题的(尤其是那些带有 regex )询问验证密码的方法.似乎用户通常会寻求密码验证方法，该方法包括确保密码包含特定字符，匹配特定模式和/或遵守最小字符数.这篇文章旨在帮助用户找到适当的密码验证方法，而不会大大降低安全性.

问题是:如何正确验证密码?

解决方案

为什么密码验证规则不正确?

我们自己的Jeff Atwood(编码恐怖的博客作者，Stack Overflow和Stack Exchange的共同创始人)早在2017年3月就写了一个有关密码规则的博客，标题为密码规则是胡扯 .如果您还没有阅读过这篇文章，我强烈建议您这样做，因为它与这篇文章的意图非常相符.

如果您从未听说过 NIST(美国国家标准技术研究院)，那么您很可能会没有为您的项目使用正确的网络安全方法.在这种情况下，请查看其数字身份准则.您还应该保持最新状态，了解网络安全的最佳做法. NIST特殊出版物800-63B(修订版3)提到以下内容有关密码规则:

验证者不应施加其他撰写规则(例如，要求 不同字符类型的混合或连续禁止 重复的字符)以存储秘密.

即使Mozilla在表单数据验证戳密码规则很有趣(页面存档在这里):

您的密码长度必须介于8到30个字符之间，并且包含一个大写字母，一个符号和一个数字"(严重吗?)

如果您为密码强加组成规则，会发生什么?您要限制潜在密码的数量，并删除与您的规则不匹配的密码排列.这使黑客能够确保他们的攻击也能做到！ 是的，但是有四千万个(1,000,000,000,000,000或1x10 ¹⁵ )密码排列" :此StackExchange Security帖子进行了扩展上面的XKCD漫画.

如何验证密码?

1.不要创建自己的身份验证

完全不再需要密码，并允许人们使用Google，Facebook，Twitter，Yahoo或您不必存储的.

_{来源:您的密码太短了杰夫·阿特伍德(Jeff Atwood).}

2.创建自己的身份验证

如果您真的必须创建自己的身份验证方法，请至少遵循经过验证的网络安全方法.以下两个部分(2.1和2.2)摘自当前的NIST出版物， 5.1.1.2部分记忆的秘密验证者.

2.1.遵循公认的网络安全方法

NIST声明您应该:

• 要求用户选择的存储秘密的长度至少为8个字符.
  • Jeff Atwood建议普通用户密码至少应为10个字符，而特权较高的用户(即管理员和主持人)则应至少为15个字符.
• 允许用户选择长度不超过64个字符或更多的存储秘密.
  • 理想情况下，您甚至不应对此设置上限.
• 允许所有打印ASCII(包括空格字符)和Unicode.
  • 出于长度要求的目的，每个Unicode代码点均应计为一个字符.
• 将潜在机密与包含已知被普遍使用，预期或折中的值的列表进行比较.例如:
  • 从先前的违规语料库获得的密码.
  • 字典中的单词.
  • 重复或连续字符(例如aaaaaa，1234abcd)
  • 特定于上下文的词，例如服务的名称，用户名及其派生词.
• 向订户提供指导，例如密码强度计.
• 实施一种速率限制机制，该机制有效地限制了可以在订阅者帐户上进行的失败身份验证尝试的次数(请参阅
• 对存储的秘密强加其他组成规则(例如，要求混合使用不同字符类型或禁止连续重复的字符).
• 要求对已存储的机密进行任意更改(例如，定期更改).

那里有很多网站，介绍了如何创建正确" 密码验证表单:这些密码中的大多数已经过时，不应使用.

3.使用密码熵

在继续阅读本节之前，请注意本节的目的不是为您提供实施自己的安全方案所需的工具，而是为您提供有关的信息当前的安全方法如何验证密码.如果您正在考虑创建自己的安全方案，则应该认真考虑三次，并阅读本文来自StackExchange的安全性社区.

3.1.密码熵概述

在最基本的级别上，可以使用以下公式来计算密码熵:

在上式中:

• 表示密码熵
• 是池中的字符数独特的字符
• 是密码中的字符数

这意味着表示可能的密码数量；或就熵而言，用尽所有可能性所需的尝试次数.

不幸的是，该公式未考虑的是诸如此类的东西:

• 通用密码:即Password1，admin
• 名称:即John，Mary
• 常用词:即英语the，I
• 反义词:即drowssap(密码反向)
• 字母替换(又名leet):即P@$$w0rd

为这些其他考虑因素添加逻辑带来了巨大挑战.请参阅3.2，了解可以添加到项目中的现有软件包.

3.2.现有的密码熵项目

在撰写本文时，用于估计密码强度的最著名的现有库是 zbox的zxcvbn (GitHub上的一个开源项目).它已经过调整，以支持.net angularjs c c# go java objec tive-c ocaml php python 休息 rust scala

---

做错了方向

但是，我了解每个人都有不同的要求，并且有时人们想用错误的方式做事.对于那些符合此条件的人(或者别无选择，并已向本节介绍了本节以上的内容，甚至更多，但他们拒绝更新其方法)，至少允许使用Unicode字符.当您将密码字符限制为一组特定字符(即确保小写ASCII字符存在a-z或指定用户可以输入或不能输入!@#$%^&*()的字符)时，您就是在自找麻烦！

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

以下正则表达式模式不适用于所有编程语言，但适用于许多主要编程语言(.net php perl python :请参见 Python正则表达式匹配Unicode属性).某些编程语言甚至拥有更好的方法来检查这种情况(例如，使用 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}])[\s\S]{8,}$

• ^在行的开头声明位置.
• (?=\P{Ll}*\p{Ll})确保至少存在一个小写字母(在任何脚本中).
• (?=\P{Lu}*\p{Lu})确保至少存在一个大写字母(在任何脚本中).
• (?=\P{N}*\p{N})确保至少存在一个数字字符(在任何脚本中).
• (?=[\p{L}\p{N}]*[^\p{L}\p{N}])确保至少存在一个不是字母或数字的字符(在任何脚本中).
• [\s\S]{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}])[\s\S]{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.
• [\s\S]{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屋！