回答
這依賴於JVM實現和可能的選項之內,但我認爲它不會清除數據。垃圾收集只需跟蹤哪些區域可用。將所有這些數據設置爲0或其他東西是很多不必要的寫入。正因如此,您經常會看到API使用char數組來獲取密碼而不是字符串。
值得一提的是,char數組只會降低攻擊成功的概率,但不能保證其完全消除。 –
@AndrewLygin對。我也沒有提到你需要自己清理陣列。數組無法避免從內存轉儲中讀取內容。 – JimmyJames
不幸的是,這裏的情況稍微複雜一些,甚至手工清理數據並不總是能夠完全擺脫它們。詳情請參閱我的回答。 –
具體甲骨文JVM不會清除空間,只伊甸園和Survivor空間,不再僅僅使用呆在那裏作爲最終將覆蓋一個垃圾對象之間複製數據。類似的事情發生在OldGen中,有些地方被標記爲已使用,並且當對象符合垃圾回收的條件時,它佔用的位置被標記爲未使用。在給定足夠的應用時間的情況下,它也會被重寫。
Oracle JVM是典型的Java VM嗎? 我更關心Android應用數據安全。 –
@李文釗Android(或者說Dalvik/ART)不是JVM,所以你不能在JVM上應用任何東西。請用'android'註釋你的問題。 Oracle是JVM的參考實現。 –
如這裏已經提到的其他用戶,JVM中不乾淨的內存垃圾收集後進行安全,因爲它會嚴重影響性能。這就是爲什麼許多程序(尤其是安全庫)使用可變結構而不是不可變(char數組而不是字符串等)並在不再需要時自行清理數據的原因。
不幸的是,即使這樣的方法並不總是奏效。讓我們來看看這種情況:
- 您使用密碼創建了一個char數組。
- JVM執行垃圾回收並將char數組移動到內存中的另一個位置,使之前佔用的內存保持不變,只是將其標記爲空閒塊。所以,我們現在有一個密碼的「髒拷貝」。
- 你已經完成了你的密碼工作,並明確地清零你的char數組中的所有字符,並認爲現在一切都安全了。
- 攻擊使你的內存轉儲,並在它被放置在第一時間內存找到您的密碼,步驟2
我能想到的唯一一個針對此問題可能的解決方案之前:
- 使用G1垃圾回收器。
- 讓您的敏感數據的單塊(原始值的陣列)足夠大,它佔用了區域大小的一半以上,由G1使用(默認情況下,這個大小取決於最大堆大小,但你也可以手動指定)。這會迫使收藏家將您的數據視爲所謂的「大型對象」。 G1 GC不會將這些對象移動到內存中。
- 在這種情況下,當你手動刪除在塊的一些數據,可以肯定的是,相同的數據的其他「髒副本」在某處堆存在。
另一個解決方案是使用您可以手動處理的堆外數據,但不會是純Java。
在Go中,您可以使用syscalls直接從內核(mmap/virtualalloc等)使用純Go請求內存。不確定在Java中是否可能有類似的東西。 – Awn
- 1. 垃圾收集java
- 2. Java垃圾收集
- 3. Java垃圾收集
- 4. 垃圾收集器如何確定對象是否是垃圾?
- 5. Java垃圾收集器澄清
- 6. 的Java newSingleThreadExecutor垃圾收集
- 7. Java垃圾收集和空
- 8. Java垃圾收集問題
- 9. Java垃圾收集算法
- 10. C#垃圾收集
- 11. GWT垃圾收集
- 12. DoctrineCommonCache垃圾收集?
- 13. 垃圾收集器
- 14. 活物是垃圾收集?
- 15. Java:垃圾回收
- 16. Java:垃圾回收
- 17. java垃圾回收
- 18. java - 垃圾回收
- 19. Java線程垃圾收集與否
- 20. 數量的垃圾收集
- 21. Java Swing JTree不是垃圾收集
- 22. 垃圾收集 - 是否需要?
- 23. 垃圾收集器是否有配置?
- 24. 垃圾收集是否影響堆棧?
- 25. 是否收集了客觀C垃圾?
- 26. GC是否從Metaspace收集垃圾?
- 27. 清單實例正在垃圾收集
- 28. Java集合和垃圾收集
- 29. 的Lua:垃圾收集用戶數據+
- 30. 清除垃圾文件kivy
相關:http://stackoverflow.com/questions/8881291/why-is-char-preferred-over-string-for-passwords-in-java – shmosel
內存安全很難做到。 同樣,當有人闖入您的手機以掃描內存中的數據時,他們幾乎可以從手機獲取大部分安全信息。 努力可以更好地保護存儲和傳輸過程中的數據。 –
這是我擔心的HIPAA合規性問題。不確定HIPAA Compliance是否需要內存加密。 –