2011-05-30 39 views
6

編輯:好了,所以我有點在這裏找到答案BCrypt says long, similar passwords are equivalent - problem with me, the gem, or the field of cryptography?jBCrypt與checkpw嚴重的問題(返回true,當它不應該?)

新的問題,雖然,一個人怎麼能推薦使用bCrypt的,如果你有散列在我們試圖教育用戶選擇日益複雜的密碼甚至密碼短語的世界中限制用戶的密碼長度,並說您的密碼必須少於n個字符,這似乎是最終在達利酷網星期五的截圖中的一種方式:)下面

原題:

我重構舊登錄應用程序的頁面,並決定使用JAVA實現jBCrypt(http://www.mindrot.org/projects/jBCrypt/)給bCrypt一個旋轉,並且碰到一個主要的節目停止。

問題是checkpw方法,當使用非常長的種子時,它似乎總是返回true。我打算用{InternalSalt} {用戶名} {密碼}將用戶的密碼加密,然後用bCrypt對其進行散列。

所以我有下面的代碼(儘量剝離它以隔離checkpw)。

public class Test { 
public static void main(String[] args) { 
    String plaintext = "jw~ct/f61y1m7q458GiLVQpiqDK|8kG=d368Id:[email protected]$^_80I{qrn1HM6423{FtestAccountO1nu3jKN"; 

    String pw_hash = BCrypt.hashpw(plaintext, BCrypt.gensalt()); 

    if (BCrypt.checkpw("jw~ct/f61y1m7q458GiLVQpiqDK|8kG=d368Id:[email protected]$^_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)

它仍然是真的!不完全是我期待的。我沒有在文檔中看到任何密碼長度的限制,但我不能用更小的密碼種子重現它,也看起來如果我修改了其他任何東西,而不是字符串的結尾,它按預期返回false。

我錯過了一些主要的東西嗎?我知道我不應該是唯一在這些論壇上使用jBcrypt的人,因爲我已經看到了BCrypt在許多帖子中推薦的同時做了一些研究。

編輯:Windows 7的64位 - 的Java(TM)SE運行時環境(建立1.6.0_24-B07)

回答

5

好了,措辭的問題給了我足夠真正弄清楚什麼我一直在尋找(歡呼爲rubber ducking)。密碼學領域現在是安全的!

BCrypt執行異或使用P_orig這是18 4個字節的整數,直到它到達最後,這將您的加密「密鑰」限制爲72個字節。在72字節之後的東西會被忽略(警告會很好)。

似乎可以接受的折衷方案並不是將用戶的密碼限制在72個字符或更少,而是讓它靜靜地通過。這背後的想法是,無論如何,一個72個字符的bCrypted密碼比快速哈希替代更好。

來源:BCrypt says long, similar passwords are equivalent - problem with me, the gem, or the field of cryptography?

2

其實你自己的答案是偉大,幫我找到惱人的問題;)有一些小費的人誰散列之前添加某種應用程序的祕密爲純(即使他們限制了密碼長度):在末端包括應用祕密,特別是如果應用的祕密長度爲72個字符 - 否則每個命中將返回true

這樣反而:

String hashed = BCrypt.hashpw(APP_SECRET + plain, BCrypt.gensalt())

使用:

String hashed = BCrypt.hashpw(plain + APP_SECRET, BCrypt.gensalt())

即使Bcrypt的裁剪將發生checkpw結果將是有效的!

相關問題