我发现下面的正则表达式用于验证密码复杂性。如何修改它以包含这些字符-_+=#^~？
^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[$@$!%*?&])[A-Za-z\d$@$!%*?&]{8,}
Minimum eight characters, at least one uppercase letter, one lowercase letter, one number and one special character
答案 0 :(得分：2)
您可以在角色类中包含这些特殊字符：
^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[-_+=#^~$@$!%*?&])[\w+=^$@$!%*?&~-]{8,}$
请记住在字符类的开头或结尾处保留未转义的连字符，并将^保留在中间，以避免将其解释为否定。
答案 1 :(得分：1)
我发现这些类型的问题一直在这里发布，特别是javascript标记。
您验证密码的方式实际上是非常错误。不要将密码限制为特定的字符集。你让黑客的工作非常轻松。有多少个字符abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_+=#^~$@!%*?&的迭代？是的，很多，但将字符限制为该集会减少可能的迭代次数。您的字符集包含76个字符。
现在让我们做一些数学运算。 76个字符，长度为8的密码（说实话，即使我们不喜欢承认，大多数用户使用的密码尽可能短，因此在您的情况下为8个字符）。这意味着这些角色可能有760,269,225,744,000个排列。
大！怎么办？再向该集添加一个字符（77个字符而不是76个字符），我们现在获得848,416,382,352,000个排列（+ 88,147,156,608,000个排列）。还有一个（78）产生945,378,254,620,800（+ 96,961,872,268,800个排列）等等。正如您所看到的，在集合中再添加一个字符会增加指数的排列数。
虽然在您的设置中添加其他字符可能实际上并不会增加密码强度（用户可能仍会在密码中使用e而不是è），但它至少会为用户提供选项试图让他们的密码变得更强。
根据OWASP (the Open Web Application Security Project) - 一个全球性的非营利组织，专注于提高软件的安全性（来自Password Storage Cheat Sheet上的文章）：
不限制字符集并设置凭据的长最大长度
有些组织限制
- 特殊字符的类型
- 系统接受的凭据长度，因为它们无法阻止SQL注入，跨站点脚本， 命令注入和其他形式的注入攻击。这些 限制，虽然善意，促进某些简单 蛮力等攻击。
不允许短密码或不长密码，也不要使用字符 对凭证的输入或存储设置或编码限制。 继续应用编码，转义，屏蔽，彻底省略，和 其他消除注射风险的最佳实践。
合理的长密码长度为160.非常长的密码策略 在某些情况下会导致DOS。
有趣的读物：Think you have a strong password? Hackers crack 16-character passwords in less than an HOUR。
所有这一切，我理解尝试帮助用户创建一个强密码。为此，您可以使用以下正则表达式（请注意，并非所有正则表达式都支持此功能，但大多数语言都支持某种形式的Unicode支持，这需要针对这些语言进行调整）。另请注意，这应该只运行服务器端，因为客户端会在 plain-sight 中向任何黑客公开有关您的密码要求的信息（是的，它仍然可能）让他们通过创建帐户并尝试使用简单密码来解决问题，但这仍然意味着他们必须付出一点努力来弄清楚什么是允许的和不允许的：）
^(?=.*\p{Ll})(?=.*\p{Lu})(?=.*\p{N})(?=.*[^\p{L}\p{N}\p{C}]).{8,}$
^在行首处断言位置(?=.*\p{Ll})确保至少有一个小写字母（在任何语言/脚本中）的正面预测(?=.*\p{Lu})确保至少有一个大写字母（在任何语言/脚本中）的正面预测(?=.*\p{N})确保至少存在一个数字（任何语言/脚本）的正面预测(?=.*[^\p{L}\p{N}\p{C}])确保至少有一个字母不是字母，数字或控制字符（在任何语言/脚本中）的正面预测.{8,}匹配任何字符8次或以上$断言行尾的位置