2016-07-28 90 views
0

所以我知道還有其他職位關於密碼存儲和加密,但我的問題是稍有不同。對我來說,裸露到底。加密一個密碼,而不要求主密碼

我正在密碼管理器網站上工作,爲了好玩。並想知道我的想法有多安全。

顯然,用戶存儲的每個密碼都使用AES-256加密,主密碼作爲密鑰和隨機生成的鹽。此外,主密碼使用Bcrypt進行加密,但在使用漩渦之類的方式之前,它會散列大約100,000次,以在嘗試登錄時增加應變。

如果用戶決定每次他/她請求站點密碼時都不想輸入密碼,程序將無法解密密碼並自動填充,因爲需要主密碼才能解密存儲的密碼。

我的一個想法是將密碼存儲在用戶當前會話中,但這不是一個好主意,因爲我試圖假設攻擊者已經違反了我的服務器並正在下載數據庫和窺探。

另一種方法是使用100,000次散列密碼作爲AES-256加密的密鑰並將該散列存儲在會話中。最好以純文本形式存儲它,但如果攻擊者能夠從會話中獲取信息,它仍然可以解密存儲的密碼。

有沒有更好的辦法解決這個問題,或者這是一個失敗的希望之戰,當我登錄時,攻擊者沒有進入?

+0

使用臨時令牌而不是傳遞哈希或密碼。 – dandavis

回答

0

如果你想完全安全,密碼應該是存儲在這樣即使沒有服務器才能解密,而無需用戶輸入的方式,因此,主密鑰永遠只能存放客戶方。

由於您不希望它存儲在會話中,您可以將它存儲在cookie客戶端,但底線是,如果入侵者已經違反了您的服務器並可以修改其代碼,以便網站按照定義,如果密碼的解密發生在服務器端,它們必須能夠獲得密碼。

所以,如果你願意,你可以寫,將接收到的AES加密字符串對於給定用戶,並會與用戶解密客戶端的一個JavaScript /客戶端應用程序輸入主密碼。與此相關的問題是,在向用戶提供加密密碼之前,您必須獲得次要信息,否則您必須願意爲所有人提供服務,否則每個人都會在需要時加密密碼。這裏還有一個額外的隱藏複雜性,如果入侵者能夠更改服務器上的代碼,他們理論上可以將其從運行的客戶端更改爲運行服務器端,從而獲得解密的密碼,或者他們可以修改客戶端JavaScript使用解密的密碼進行AJAX調用。

而且主密碼使用Bcrypt加密的,但是手之前已哈希使用類似的旋渦,以提高應變嘗試登錄

沒有必要當,只是一些10萬次增加Bcrypt的強度參數以增加登錄時的時間。 Bcrypt內置了密鑰擴展功能。

0

不幸的是,你必須在安全性和便利性之間進行選擇。

人們可能難以獲得鑰匙,例如,使用基於硬件的解決方案,但最後在某些時候,您的應用程序必須能夠以純文本格式檢索存儲的密碼。如果攻擊者完全控制了服務器,則不會阻止他執行完全相同的步驟。

對於最大的安全性,甚至沒有服務器必須能夠解密存儲的密碼,如果關鍵仍然在客戶端,這只是可能。你可以做的是爲客戶端編寫一個應用程序,並使用服務器來存儲加密的密碼存儲庫。

順便說一句,在BCrypt算法已經做關鍵拉伸,因此沒有必要添加散列的額外回合。在這種情況下,更好的解決方案是增加成本因素​​。