我有一個連接數據庫的Java應用程序。數據庫的用戶名和密碼存儲在屬性文件中。避免在屬性文件中以明文形式存儲密碼，同時仍保留允許用戶更改選項的常見做法是什么？這里的主要動機是防止在管理員編輯屬性文件時有人看著管理員的肩膀并看到密碼。我在這里閱讀到有一種內置的方法可以在C＃中完成。了解Java，我不希望找到一個內置的解決方案，但我想聽聽其他人在做什么。如果找不到任何好的選擇，那么我可能會使用將保留在代碼中的恒定密碼對其進行加密。但是我不喜歡這樣做，因為它感覺不對。 看起來沒有魔法，我必須將密碼存儲在代碼中或類似的內容中。最后，我們實現了與答案之一中提到的Jasypt非常相似的東西。所以我接受Jasypt答案，因為它是最確定的答案。
3 回答
慕尼黑8549860
TA貢獻1818條經驗 獲得超11個贊
窮人妥協解決方案是使用簡單的多重簽名方法。
例如，DBA將應用程序數據庫密碼設置為50個字符的隨機字符串。 TAKqWskc4ncvKaJTyDcgAHq82X7tX6GfK2fc386bmNw3muknjU
他或她將一半的密碼提供給應用程序開發人員，然后將其硬編碼為Java二進制文件。
私人字符串pass1 =“ TAKqWskc4ncvKaJTyDcgAHq82”
密碼的另一半作為命令行參數傳遞。DBA將pass2交給系統支持人員或管理員，后者可以輸入pass2作為應用程序的啟動時間，或者將其放入自動化的應用程序啟動腳本中。
java -jar /myapplication.jar -pass2 X7tX6GfK2fc386bmNw3muknjU
當應用程序啟動時，它使用pass1 + pass2并連接到數據庫。
該解決方案具有許多優點，而且沒有提及的缺點。
您可以安全地將一半密碼放在命令行參數中，因為除非您是擁有另一半密碼的開發人員，否則閱讀它不會有多大幫助。
DBA仍然可以更改密碼的后半部分，并且開發人員無需重新部署應用程序。
讀取源代碼時，源代碼也可以是半公開的，并且密碼不會授予您應用程序訪問權限。
您可以通過增加對數據庫將接受其連接的IP地址范圍的限制來進一步改善這種情況。
Smart貓小萌
TA貢獻1911條經驗 獲得超7個贊
如何提供自定義的N因素身份驗證機制？
在合并可用方法之前，讓我們假設我們可以執行以下操作：
1）Java程序內部的硬代碼
2）存儲在.properties文件中
3）要求用戶從命令行鍵入密碼
4）要求用戶從表格中輸入密碼
5）要求用戶從命令行或表單加載密碼文件
6）通過網絡提供密碼
7）許多替代方法（例如，“畫出秘密”，指紋，特定于IP，bla bla bla）
第一種選擇：我們可以通過混淆使攻擊者的事情變得更復雜，但這并不是一個好的對策。優秀的編碼人員可以訪問文件，從而輕松理解其工作原理。我們甚至可以導出每個用戶的二進制文件（或僅導出混淆部分或密鑰部分），因此攻擊者必須有權訪問此用戶特定的文件，而不是另一個發行版。同樣，我們應該找到一種更改密碼的方法，例如通過重新編譯或使用反射來即時更改類行為。
第二個選擇：我們可以將密碼以加密格式存儲在.properties文件中，因此攻擊者無法直接看到它（就像jasypt一樣）。如果我們需要密碼管理器，我們也將需要一個主密碼，該密碼又應該存儲在某個地方-在.class文件，密鑰庫，內核，另一個文件甚至在內存中-都有各自的優缺點。
但是，現在用戶只需編輯.properties文件即可更改密碼。
第三個選項：從命令行運行時輸入密碼，例如java -jar /myprogram.jar -p sdflhjkiweHIUHIU8976hyd。
不需要存儲密碼，它將保留在內存中。但是，history命令和OS日志可能是您最大的敵人。要即時更改密碼，您將需要實現一些方法（例如，監聽控制臺輸入，RMI，套接字，REST等等），但是密碼將始終保留在內存中。
甚至可以僅在需要時才對其進行臨時解密->然后刪除解密的內容，但始終將加密的密碼保留在內存中。不幸的是，前述方法并未增加針對未經授權的內存中訪問的安全性，因為實現該目的的人可能將有權訪問所使用的算法，鹽和任何其他秘密。
第四個選項：從自定義表單（而不是命令行）提供密碼。這將避免測井暴露的問題。
第五個選項：提供一個文件作為密碼，該文件先前存儲在另一種介質上->然后硬刪除文件。這將再次規避伐木暴露的問題，再也不需要敲擊可能會被偷來的打字。如果需要更改，請提供另一個文件，然后再次刪除。
第六種選擇：再次避免肩并肩沖浪，可以實施RMI方法調用，從另一個設備（例如，通過移動電話）提供密碼（通過加密通道）。但是，您現在需要保護網絡通道并訪問其他設備。
我將選擇上述方法的組合以實現最大的安全性，因此必須訪問.class文件，屬性文件，日志，網絡通道，肩膀沖浪，中間人以及其他文件。使用所有sub_password之間的XOR操作可以很容易地實現此操作，以產生實際的密碼。
但是，我們不能免受未經授權的內存訪問的保護，這只能通過使用某些訪問受限的硬件（例如，智能卡，HSM，SGX）來實現，其中將所有內容都計算在內，沒有任何人，甚至沒有合法的所有者能夠訪問解密密鑰或算法。同樣，人們也可以竊取這種硬件，據報道有側通道攻擊可以幫助攻擊者提取密鑰，在某些情況下，您需要信任另一方（例如，使用SGX，您可以信任英特爾）。當然，當安全區域克?。ú鹧b）成為可能時，情況可能會惡化，但是我認為這將需要幾年才能實現。
同樣，可以考慮一種密鑰共享解決方案，其中將完整密鑰分配給不同的服務器。但是，在重建時，完整密鑰可能會被盜。緩解上述問題的唯一方法是通過安全的多方計算。
我們應該始終牢記，無論采用哪種輸入方法，都需要確保我們不容易受到網絡嗅探（MITM攻擊）和/或鍵盤記錄程序的攻擊。
添加回答
舉報
0/150
提交
取消