问不区分大小写的密码是个坏主意吗？

EN

你是否应该担心取决于你所保护的东西的敏感性。保护我的文件柜的锁不需要那么安全，我也不担心锁的设计成本很低。但我希望保护我的钱的锁非常安全。这确实表明，在设计系统时，他们可能没有非常清楚地考虑安全性问题。

使密码不区分大小写，大大减少了可能性。6个不区分大小写字符的字母表只有2^28个可能的密码，而6个字符区分大小写的密码有2^34个可能的密码。这样减少了搜索空间，使得对泄漏的散列数据库的攻击更加可行。

正如杰夫·费兰德( Jeff )在下面指出的那样，设置大写锁并不意味着网站不区分大小写。如果我输入密码，然后点击大写锁，它就会出现Password。这个案子只是倒过来的。如果站点正在这样做，那么密码仍然是区分大小写的，但只是尝试原始密码和反向密码。这只是将搜索空间减半。这只是一种可用性/安全性的权衡，因为人们通常都有上限锁定而不知道，而且(至少IMO)是一个很好的选择。

从这一事实来看，服务是否以明文形式存储密码是不可能的。在散列完成之前，将所有内容都更改为一种情况是很简单的。

密码系统是否将您的密码存储在明文中，与是否区分大小写无关。许多设计糟糕的系统需要区分大小写的密码，但需要用明文存储。

。

至于您是否应该关注，任何不需要区分大小写密码的系统都会将唯一密码的数量减少一半或更少。它可能对用户很方便，但例如，一个不区分大小写的8个字符密码有208,827,064,576 (2080亿)可能的变化。区分大小写? 53,459,728,531,456 (53万亿)组合。当情况不成问题时，蛮力破解者需要运行的时间要小得多才能找到您的密码。加上数字(0-9)，这个数字是213万亿的四倍。

当然，用户往往忽略好的密码安全功能，例如使用强混合字符密码，不重用密码，定期更改密码，不使用字典单词，因此他们可能已经决定不需要太复杂的密码。

与caps锁有关的行为不会告诉您服务器端使用的哈希算法。

它可能是服务器上的散列，确实是使用您输入的密码计算的。但是，对于无效的密码，服务器可能只是将您输入的每个字母的情况颠倒过来，然后再试一次。这种方法实际上对安全性没有影响，但如果用户经常忘记他们的caps锁已开启，则可能会大大减少支持案例的数量。

也有可能密码根本不区分大小写。再说一遍，它没有告诉你任何关于哈希的事。在散列之前，他们可能只是将整个密码转换为小写(或大写)。这减少了可能的熵的数量，因此在这样的系统中，您的密码需要长约15%才能有相同的强度。