1

To store user passwords I am going to SHA 256 + salting. Just wanted to confirm if these are correct. Business requirement is password should be minimum 8 inputs and maximum 32 inputs. (any input is valid except blank space)

So to meet these requirements the plan is:
Front end - validate max input of 32 & min input of 8.

Backend the Database (MySQL) schema will be:
pass_hash(64) CHAR - store password hash
pass_slt(32) VARCHAR - store unique salt for each user

For salting I am not sure what value to use as yet. But i think when users create an account I will create a random character for each user and use that. Then the other question is: Do i store the salt as plain text or need to hash/encrypt that too?

Also I dont know if it matters but can passwords support multi-language with this current plan or will I run into any issues? (I am talking about funky characters like Arabic, Chinese, etc)

4

2 回答 2

1

关于盐：

盐是公共数据（如果它是保密的，那么它就不会被称为“盐”而是“密钥”）。必须知道盐才能验证密码（因为它与密码一起进入散列函数），因此它以明文形式存储，就像您打算做的那样。

加盐的目的是防止攻击者在攻击实例之间分摊攻击成本。猜测用户选择的密码通常是可能的（用户只有人类大脑，很少擅长记住复杂的密码）。盐确保，至少，攻击者必须为每个被攻击的密码支付密码猜测的全部代价（即“尝试”一个可能密码的大字典）。

只要每个密码都是唯一的，盐就可以很好地工作。请注意，每个用户的唯一性是不够的：有时，用户更改了他们的密码，而您不希望下一个密码使用相同的盐（否则，攻击者可以使用某种程度的成本分摊）。因此，您希望在存储密码的任何时候选择一个新的盐，即创建帐户时和更改密码时。

使用足够大的随机盐很容易确保盐的唯一性。32 字节的盐就足够了：选择两次相同的盐（运气不好）的风险可以忽略不计。

除了加盐之外，另一个安全级别是使密码散列变得“昂贵”。例如，当您对（加盐的）密码进行哈希处理时，实际上是对盐+密码序列的 10000 倍的串联进行哈希处理。这使得密码验证成本高出 10000 倍，对您和攻击者都是如此。通常情况下，合法密码验证可以在计算上变得更重而没有明显影响（即使您每秒检查 100 个用户密码，您仍然可以为此投入 100µs，它只会使用您 1% 的处理时间），但是让攻击者的难度增加 10000 倍是个好主意。

关于语言：

非 ASCII 密码的主要问题是某些字形可能使用多种编码。例如，可以使用 Unicode 将“é”编码为单个代码点（U+00E9 带有锐音的拉丁小写字母 E）或两个代码点（U+0065 拉丁小写字母 E，然后是 U+0301 COMBINING尖锐的口音）。请注意，这个例子是关于一个相当常见的法语字母，没有什么比中文或韩文更花哨（计算机方面）。编码问题可以通过Unicode 规范化表单来处理，但这不是一项简单的编程任务。一些编程环境可以提供帮助（例如，在 Java 中，使用java.text.Normalizer实现了 UNF 的 ）。

此外，对于切换键盘的用户来说，非 ASCII 密码可能难以输入，例如，当用户想要在旅馆或机场使用共享计算机时（无论如何，在此类系统上键入敏感密码并不是一个好主意）。

如果可能，我建议尝试强制使用仅 ASCII 密码，或者硬着头皮：执行 UNF（使用 NFD 形式），然后执行 UTF-8 编码。由此产生的字节序列是进入散列阶段的。

于 2010-11-03T13:51:32.290 回答
-1

看起来差不多，除了盐应该是固定长度（例如总是32字节）；你是对的，它应该是随机的和每个用户的。我认为加密盐没有任何真正的好处。当攻击者已经拥有数据库的明文版本时，Salts 可以防御这种情况。

至于多语言，您应该对您在应用程序中使用的字符编码以及您调用 SHA-256 的确切内容保持一致。

于 2010-11-03T06:09:34.827 回答