[Sql-Server]在密码盐和哈希值中使用什么数据类型，以及应该使用多少长度？

Question

我正在使用以下方法从密码生成salt和hash值：

string salt = CreateSalt(TxtPassword.Text.Length);
string hash = CreatePasswordHash(TxtPassword.Text, salt);

private static string CreateSalt(int size)
{
    //Generate a cryptographic random number.
    RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
    byte[] buff = new byte[size];
    rng.GetBytes(buff);

    // Return a Base64 string representation of the random number.
    return Convert.ToBase64String(buff);
}

private static string CreatePasswordHash(string pwd, string salt)
{
    string saltAndPwd = String.Concat(pwd, salt);
    string hashedPwd =
     FormsAuthentication.HashPasswordForStoringInConfigFile(
     saltAndPwd, "sha1");

    return hashedPwd;
}

你建议在SQL Server中使用什么数据类型来存储这些值？有什么建议吗？...

盐：9GsPWpFD

哈希：E778AF0DC5F2953A00B35B35D80F6262CDBB8567

- ACP

Answer 1

ASPNET_DB 表示 - 绝对没错。

Password nvarchar(128) NOT NULL,
PasswordSalt nvarchar(128) NOT NULL,

虽然128看起来很多，但各种加密类型可能会导致比原始字符串更大的字符串。没有任何理由不遵循那些花费了数千个工时开发asp.net成员身份系统的非常聪明的人的领导。

- Sky Sanders

---

抱歉，但“微软很聪明，我很蠢，我听从老板”的态度是不好的。特别是考虑到微软有时会发布大量愚蠢的信息。请提出论据。 - TomTom

@tomtom - 哇，我猜你在实施安全堆栈方面有很多经验，并且已经检查过组成非常强大而灵活的asp.net提供程序堆栈的每一行源代码、列和存储过程，以支持你对我的陈述的总结判断。嗯……我认识符合这个描述的人...... - Sky Sanders

我确实这样做了。但我也尝试使用自己的头脑，不盲目跟随其他人可能做过的事情——出于完全不同的原因，你甚至不想给出。顺便说一句，我真的怀疑即使微软花费了数千（！）个工时开发asp.net成员资格系统，其他人可能总共只需要100个左右。而且你知道成员资格系统是在晚些时候的.NET版本中“附加”上去的，聪明的人们完全忽视了通过任何手段使其可扩展性？微软并不完美。 - TomTom

实际上，将密码设置为nvarchar（128）是有意义的，因为成员提供程序允许在数据库中存储未加密的密码（如果配置为这样做），在这种情况下，长度和特殊字符都可能被允许。这是完全愚蠢的不良实践，但是提供程序模型是通用且可配置的，并且还考虑了低安全性场景。请注意，非ASCII字符作为密码总是很愚蠢的 - 您永远不知道是否需要从互联网咖啡馆登录，并且不能在这种情况下依赖键盘设置。 - TomTom

128对于我的密码哈希非常完美，其中包括三次哈希迭代和添加盐。 - user460114

Answer 2

我们将密码存储为二进制SHA512哈希值

- Joe Phillips

---

如果不使用盐值，那就是非常愚蠢和极其疏忽的行为，因为这意味着简单的字典攻击可以轻松破解密码 - 而且随着密码列表中密码数量的增加，破解速度会越来越快。 - TomTom

你可以用盐做同样的事情。 - Joe Phillips

@JoePhilllips 我认为他指的是彩虹表攻击，使用盐可以避免这种攻击。 - ghord

@ghord 我不反对。无论哪种方式，你都要对加盐的密码进行哈希处理，然后将其存储为二进制SHA512哈希值（我猜它技术上已经不再是密码了）。 - Joe Phillips