[Sql-Server]密码盐和哈希值使用啥数据类型以及啥长度？

Posted 2023-02-24

【中文标题】[Sql-Server]密码盐和哈希值使用啥数据类型以及啥长度？

【英文标题】：[Sql-Server]what data type to use for password salt and hash values and what length?[Sql-Server]密码盐和哈希值使用什么数据类型以及什么长度？

【发布时间】：2011-02-21 05:24:41

【问题描述】：

我正在使用我的密码生成盐值和哈希值，

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

【参考方案1】：

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

【讨论】：

不使用盐，这是愚蠢和严重的忽视，因为这意味着简单的字典攻击可以破解密码 - 并且这样做越快，您的列表中的密码就越多。

你可以用盐做同样的事情

@JoePhilllips 我认为他提到了彩虹表攻击，使用盐时可以避免这种攻击。

@ghord 我不反对。无论哪种方式，您都对加盐密码进行哈希处理，并将其存储为二进制 SHA512 哈希（我想从技术上讲，它不再是密码了）

【参考方案2】：

ASPNET_DB 这么说 - 不会出错。

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

虽然 128 看起来很多，但各种类型的加密可能会产生比您开始时更大的字符串。绝对没有理由不跟随那些花费数千工时开发 asp.net 会员系统的非常聪明的人。

【讨论】：

-1 / 对不起，但是“微软很聪明​​，我很愚蠢，我跟着马萨”是一种不好的态度。特别是考虑到微软有时会发出大量的愚蠢行为。提出论据。

@tomtom - 哇。我想您在实现安全堆栈方面拥有丰富的经验，并且已经了解了构成非常健壮和灵活的 asp.net 提供程序堆栈的每一行源代码、列和存储过程，以支持您对我的陈述的总结判断。嗯……我认识一个符合这种描述的人……

嗯，我做到了。但我也尝试使用我的大脑，而不是盲目地追随其他人可能做过的事情——出于完全不同的原因，你甚至不想给出。顺便说一句，当其他人总共花费 100 左右时，我严重怀疑即使是 MS 也会花费数千（！）工时来开发 asp.net 会员系统。而且您知道会员系统在后来的 .net 版本中被“添加”在聪明人完全忽视以任何方式使其可扩展之后？ MS 并不完美。

@Pandiya - 嗯，这真的取决于你的盐的大致长度。我怀疑类似的长度完全不符合惯例，而不是预期的必要性。你可以毫无问题地减半。但是我会保留一个可变长度字段，除非你想修剪你的查询结果，在 CHAR 的情况下，或者在二进制的情况下转换为字节/字符串以便比较。宽类型 (N) 可能不是必需的，但同样，它可能是出于惯例和一致性。

实际上密码为 nvarchar(128) 是有道理的，因为如果这样配置，成员资格提供程序允许在数据库中存储未加密的密码 - 在这种情况下，长度和特殊字符都可以被允许。这是完全愚蠢的坏做法，但是提供者模型是通用的和可配置的，并且还考虑了低安全性场景。请注意，虽然非 ascii 字符作为密码总是很愚蠢 - 您永远不知道是否需要从网吧登录，并且在这种情况下不能依赖键盘设置。