编辑:好的,我在这里找到了一个答案BCrypt says long, similar passwords are equivalent - problem with me, the gem, or the field of cryptography?
新问题但是,如果你在我们试图教育用户选择越来越复杂的密码,甚至是密码短语,说密码必须更短的世界中,如果你必须限制用户的密码长度,有人怎么建议使用bCrypt进行散列?超过n个字符似乎是一种方式,最终在thedailywtf.com星期五的截图:)
以下原始问题:
我正在为一个应用程序重构一个旧的登录页面,并决定使用JAVA实现jBCrypt(http://www.mindrot.org/projects/jBCrypt/)给bCrypt一个旋转,并遇到一个主要的显示停止。
问题在于 checkpw 方法,当使用非常长的种子时,该方法似乎总是返回true。我打算使用{InternalSalt} {username} {password}来填写用户的密码,然后使用bCrypt对其进行哈希处理。
所以我有以下代码(尽可能地将其剥离以隔离checkpw)。
public class Test {
public static void main(String[] args) {
String plaintext = "jw~ct/f61y1m7q458GiLVQpiqDK|8kG=d368Id:D@$^_80I{qrn1HM6423{FtestAccountO1nu3jKN";
String pw_hash = BCrypt.hashpw(plaintext, BCrypt.gensalt());
if (BCrypt.checkpw("jw~ct/f61y1m7q458GiLVQpiqDK|8kG=d368Id:D@$^_80I{qrn1HM6423{FtestAccountO1nu3jKN", pw_hash))
System.out.println("It matches");
else
System.out.println("It does not match");
}
}
这将打印出“匹配”。
我遇到的问题就是说你将 aaa 添加到你传给checkpw制作的密码
BCrypt.checkpw(“jw~ct / f61y1m7q458GiLVQpiqDK | 8kG = d368Id:D @ $ ^ _ 80I {qrn1HM6423 {FtestAccountO1nu3jKNaaa”,pw_hash)
它仍然是真的!不完全是我所期待的。我没有在doc中看到任何密码长度限制但是我无法用较小的密码种子重现它,看起来如果我修改除了字符串结尾之外的其他任何东西,它按预期返回false。
我是否错过了一些专业?我知道我不应该是唯一一个在这些论坛上使用jBcrypt的人,因为我看过BCrypt在做一些研究时在很多文章中都推荐过。
编辑:Windows 7 64位 - Java(TM)SE运行时环境(版本1.6.0_24-b07)
答案 0 :(得分:5)
好的,所以这个问题的措辞足以让我真正弄清楚我在寻找什么(欢呼rubber ducking)。密码学领域现在是安全的!
BCrypt使用P_orig实现XOR,它是18个字节的整数,直到它结束,这将加密“密钥”限制为72个字节。忽略72字节后的Eveyrything(警告本来不错)。
似乎接受的折衷方案不是将用户的密码限制为72个字符或更少,而只是让它以静默方式通过。这背后的想法是72字符bCrypted密码比快速哈希替代品更好。
答案 1 :(得分:2)
实际上你自己的回答是很好并帮助我找到烦人的问题;)对于在散列之前添加某种 app秘密的人有一些提示(即使他们限制密码长度):在结束包含应用秘密,特别是如果应用的秘密是72个字符长 - 否则每个匹配将返回true
!
所以相反:
<击> String hashed = BCrypt.hashpw(APP_SECRET + plain, BCrypt.gensalt())
击>
使用:
String hashed = BCrypt.hashpw(plain + APP_SECRET, BCrypt.gensalt())
即使发生Bcrypt的裁剪,checkpw
结果也会有效!