aWallet 密碼管理器
在閱讀了很多關於提高網路帳戶安全性的文章後，我開始使用aWallet Password Manager來備份
Android我的密碼。我喜歡它的原因如下：
- 我能夠擁有相當好的熵密碼：我能夠混合使用小寫和大寫字母、數字、特殊字元（包括空格）並擁有相當長的密碼（10+ 個字元）
- 安全地保存我的密碼允許我**為每個網路帳戶設置不同的密碼，**否則這是不可能的。如果我的一個帳戶（我與多個帳戶共享其登錄憑據）被洩露，這將避免級聯效應（洩露所有帳戶的憑據）。
不用說，第二點值得商榷，因為將所有憑證儲存在一個地方會引入單點故障，並帶來前面提到的連鎖反應的同等風險。
鑑於我
Cryptography對隱私的了解和懷疑（鑑於最近發生的線上盜竊事件），我想在將我的銀行/卡詳細資訊aWallet Password Manager儲存在其中之前證明其安全性。以下是他們在Google PlayStore 頁面上聲明的內容：安全功能
• 所有數據都經過加密，包括條目名稱、類別定義和數據本身。
• 使用密鑰大小為 256、192 和 128 位的 AES 和 Blowfish 算法加密數據。
• 解密數據文件時，使用主密碼嘗試最多算法、密鑰大小和密碼操作模式（CBC、CFB、OFB 和ECB）的所有組合來解鎖數據文件。這使得蠻力攻擊更長。應用程序本身不儲存任何有關實際密碼、密鑰大小或密碼操作模式的提示。
• 使用隨機生成的“salt”與主密碼相結合。Salt有助於防止離線字典攻擊。
• 打開數據文件的密鑰是通過將您的主密碼與 512 位“salt”結合起來創建的。結果由 SHA-256 散列 1000 次。重複散列使蠻力攻擊更加困難。
雖然這些點對我來說沒有多大意義，但我所知道的一點點
Cryptography告訴我，重複Cipher多次並不能從數學上提高安全性；它可能只會給人一種增加安全性的錯誤印象。由於這種不一致，我開始懷疑他們其他說法的有效性。您能否詳細說明他們的主張/指出一些來源，以便我可以對這些概念進行概述以消除我的懷疑；以證明或反駁aWallet Password Manager提供的安全級別？
詳細闡述他們的主張/向我指出一些來源，在那裡我可以對這些概念進行概述以消除我的懷疑
該答案將集中在問題的這一部分：詳細說明列出的聲明。
所有數據都經過加密，包括條目名稱、類別定義和數據本身。
只要這不妨礙從數據庫中檢索資訊等功能，那麼它應該沒問題。
使用密鑰大小為 256、192 和 128 位的 AES 和 Blowfish 算法加密數據。
我希望/假設這意味著它提供了這些密鑰大小的選項，而不是它使用 AES-256、AES-192和AES-128 來加密每個數據塊。如果確實如此，那將是一個非常糟糕的信號，不是出於加密漏洞的原因，而是更重要的是，因為這意味著作者不了解他們在做什麼。
使用 Blowfish 沒有任何好處。甚至 Blowfish 的作者也認為人們應該停止使用 Blowfish。
由於 Blowfish 的塊大小較小，可能會出現複雜情況，但如果不確切知道正在做什麼，例如應用密碼的順序，很難知道。
解密數據文件時，使用主密碼嘗試最多算法、密鑰大小和密碼操作模式（CBC、CFB、OFB 和 ECB）的所有組合來解鎖數據文件。這使得蠻力攻擊更長。應用程序本身不儲存任何有關實際密碼、密鑰大小或密碼操作模式的提示。
假設密碼、密鑰大小和操作模式是安全的，這只是浪費使用者時間和設備電池。這不是一個好兆頭，並試圖通過默默無聞來提供安全性。
如果只有 4 種操作模式 - 沒有一種提供身份驗證 - 並且它們是隨機選擇的，那麼猜測操作模式最多提供 2 位安全性。
如果只有兩種密碼選擇 - AES 和 Blowfish - 並且它是為每個密碼隨機選擇的，那麼它提供了額外的 1 位安全性。
如果只有 3 種密鑰大小 - 128、192 和 256 位 - 並且它是為每個密碼隨機選擇的，那麼它提供了額外的 1.5 位安全性。
假設這些都是用每個密碼的隨機選擇呼叫的，那麼它最多提供 4.5 位的額外安全性。
減慢暴力破解的正確方法是使用大量迭代和應用於密碼的密鑰派生函式。
請注意，完全使用歐洲央行模式是一個很大的危險信號。
使用隨機生成的“鹽”與主密碼相結合。Salt有助於防止離線字典攻擊。
這很好。但是，使用 512 位 salt 的大小是需要的兩倍。
打開數據文件的密鑰是通過將您的主密碼與 512 位“鹽”結合起來創建的。結果由 SHA-256 散列 1000 次。重複散列使蠻力攻擊更加困難。
SHA-256 的 1000 次迭代是不夠的，並且僅在安全性方面提供了微不足道的改進。SHA-256 的設計並不能阻止攻擊者使用 GPU/FPGA/ASIC 來計算每秒的密碼猜測次數（大約數十億）。
理想情況下，實際的密鑰派生函式（如 PBKDF2、scrypt 或 Argon2）將與更大的迭代次數（100,000-1,000,000）一起使用，並設置為盡可能/可容忍地消耗盡可能多的記憶體，以提高定製成本硬體並儘可能減少攻擊者的優勢。
也許使用者不想在 100,000 次迭代中耗盡電池 - 但是，在這種情況下，迭代計數應該可以配置為具有合理安全的預設值。SHA-256 的 1,000 次迭代不是一個相當安全的預設值。
缺乏認證
這些描述沒有提到任何關於經過身份驗證的加密。缺乏身份驗證意味著攻擊者可以修改密文，而使用者將無法檢測到修改。
不提供經過身份驗證的加密是一個巨大的危險信號。
結論
考慮到的所有這些點意味著相關軟體的作者並不完全理解他們在做什麼。您應該強烈考慮尋找一個經過更嚴格審查且由知識淵博的人編寫的應用程序。一些缺陷非常嚴重，可能導致現實世界中使用者數據的洩露。