我的密码盐应该有多大？
可能的重复：
用户密码盐的最佳长度是多少？
我有一个如下所示的数据库：
create table user (id int primary key auto increment,
username varchar(64),
password varchar(128), # sha512 hash of password
password_salt varchar(128) # sha512 hash of a random number used as salt
)
这是使用盐确保密码安全的好主意吗？盐应该放多长时间？我认为拥有 128 位（SHA-512）盐不会有什么坏处，但我以前就错了。
Possible Duplicate:
What is the optimal length for user password salt?
I have a database like below:
create table user (id int primary key auto increment,
username varchar(64),
password varchar(128), # sha512 hash of password
password_salt varchar(128) # sha512 hash of a random number used as salt
)
Is this a good idea for ensuring password security with a salt? How long should a salt be? I assume that it can't hurt to have a 128bit (SHA-512) salt, but I've been wrong before.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我有几个评论：
盐应该是随机的并且每个用户都是唯一的，但是它们不必是哈希摘要。盐的想法只是使每个用户的哈希摘要都是唯一的，以抵抗字典攻击和彩虹表攻击。无论盐的长度如何，盐都不会增加哈希摘要算法的强度。
DES 使用 12 位作为盐。更新的 UNIX 密码系统使用更多，最多 128 位。
如果您想要更强的密码，请考虑使用 bcrypt 或 PBKDF2。
FWIW，无论输入的长度如何，SHA-512 哈希摘要（编码为十六进制数字）始终恰好是 128 个字符。所以我会使用 CHAR(128) 而不是 VARCHAR(128)。使用 BINARY(2) 或 BINARY(3) 作为盐。
I have several comments:
Salts should be random and unique per user, but they don't have to be a hash digest. The idea of a salt is just to make the hash digest unique per user to resist dictionary attacks and rainbow table attacks. The salt doesn't add to the strength of the hash digest algorithm, regardless of the salt's length.
DES uses 12 bits for the salt. Updated UNIX password systems use more, up to 128 bits.
If you want stronger passwords, consider using bcrypt or PBKDF2.
FWIW, a SHA-512 hash digest (encoded as hex digits) is always exactly 128 characters, regardless of the length of the input. So I'd use CHAR(128) instead of VARCHAR(128). Use BINARY(2) or BINARY(3) for the salt.