向 .htpasswd 添加盐?
是否可以在 .hpasswd 文件中的密码中添加盐?我认为不会,因为服务器需要每个用户的盐来验证密码,而且我无法想象它将如何获取它们,但否则如果要获取列表,它将相当容易受到攻击。有解决办法吗?
非常感谢您的帮助, 本
Is it possible to add a salt to passwords in .hpasswd files? I assume not since the server would need the salt for each user in order to verify the password and I can't think of how it would get them, but otherwise if the list was to be obtained it would be rather vulnerable. Is there a solution?
Many thanks for your help,
Ben
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
默认情况下,htpasswd 使用标准 crypt 函数,因此密码已经加盐 - 请注意此示例 具有相同的密码,但哈希值不同:(
注意:通常不鼓励使用
-b
标志,因为其他用户可以看到您的命令行参数,从而看到密码)两个用户 哈希值是盐;通过再次调用
crypt()
来验证密码。输入错误的密码会产生一个与散列密码不相等的字符串:而正确的密码会产生预期的散列:
htpasswd -m
使用基于 MD5 的不同算法并使用更长的盐:这里, salt 是第二个和第三个
$
之间的 8 个字符。htpasswd -s
存储不带盐的 SHA-1 摘要;这似乎是为了与 Netscape/LDIF 兼容:这些可以轻松逆转 - 转换为十六进制摘要:
然后使用 在线哈希数据库。
By default htpasswd uses the standard crypt function and thus passwords are already salted - note in this example that both users have the same password yet the hashes are different:
(note: the
-b
flag is normally discouraged because other users can see your command line arguments and hence the password)The first two characters of the hash are the salt; passwords are verified by calling
crypt()
again. Entering the wrong password produces a string that's unequal to the hashed password:whereas the correct password produces the expected hash:
htpasswd -m
uses a different algorithm that's MD5-based and uses a longer salt:Here, the salt is the 8 characters between the second and third
$
.htpasswd -s
stores a SHA-1 digest with no salt; this appears to be for compatibility with Netscape/LDIF:These can easily be reversed - convert into a hex digest:
then use an online hash database.
htpasswd
实用程序已经在以下位置使用盐大多数情况:这就是密码文件中盐的(某种程度上)目的。虽然盐必须包含在服务器的
.htpasswd
文件中,服务器才能检查密码,但盐的多种不同可能性可以防御诸如 彩虹表。但是,如果您的用户选择弱密码或通用密码,那么密码破解无论如何都是一个问题,因为攻击者(假定有权访问密码文件)将首先尝试这些密码,实际上很快(不受服务器速度和速度的限制)互联网连接),通过正常方式猜测。我能给出的最好建议是用户应该始终选择强密码。
The
htpasswd
utility already does use salts in most cases:And that's (sort of) the purpose of salts in password files. While salts have to be included in the server's
.htpasswd
file for the server to be able to check passwords, it is the numerous different possibilities of what a salt could be that defends against such attack techniques as rainbow tables.However, if your users pick weak or common passwords, password cracking is a problem anyways, since the attacker (presumed to have access to the password file) will try those first, very quickly in fact (not limited by the speed of the server and Internet connection), by guessing in the normal way. The best advice I can give is that users should always pick strong passwords.