東西存儲在內存中有多安全？

假設我有一個程序將文件讀入內存並使用某些內容（例如rijndael/AES）來解密它。新的未加密流/字符串/我的程序在內存中保存的內容有多受保護？我意識到即使嘗試它也需要一些內存技巧，但我只是好奇而已。我不太瞭解關於.NET/VS2010的編程/堆棧/內存工作方式，所以我很抱歉。在那個說明中，硬編碼的字符串有多安全（例如，連接到SQL服務器的連接字符串將包含用於軟件的user/pw）？東西存儲在內存中有多安全？

來源

2011-03-13 Jeff Plott

它與您在運行時在計算機上使用或使用的任何其他敏感數據一樣安全或不安全，因爲這些內容也是通過應用程序和內存來實現的。正如你所說，在某些情況下，如果應用程序正在使用或者由最終用戶理解，所有內容都不會在內存中加密。我在說的是我認爲這個問題並不是特定於.NET/VS2010，特別是不是C＃，因爲這是一種語法 - 您可能需要使用[CIL]標記。 HTTP：//en.wikipedia。org/wiki/Common_Intermediate_Language – 2011-03-13 04:28:56

即使你對連接字符串進行了加密，通過數據包嗅探或DLL注入或其他方式來捕獲它們也應該是微不足道的。底線：永遠不要讓人們直接訪問數據庫，放置Web服務或其他內容。 – 2011-03-13 04:32:34

硬編碼字符串根本不安全。從.exe文件中提取所有字符串是一件微不足道的事情。

內存中是比較安全的。現代操作系統有很多內存保護，以防止一個進程讀取/修改另一個進程的內存。這將防止間諜軟件從另一個進程的內存段讀取密碼。

只要你的過程只在內存中保存的加密值（從來沒有把它寫到一個文件，將其發送，將其存儲在數據庫中，等等），它可能是足夠安全的。

對於超級機密數據，您必須關心熱重啓。這是您的程序在內存中保存未加密的數據時，用戶重新啓動機器並繼續讀取所有主內存。在這種情況下，內存仍可能包含未加密的信息。然而，這是相當的極端，並且（對於大多數應用程序）不值得擔心。

綜上所述：在內存中

未加密的數據= OK
未加密的數據在.exe文件的硬編碼=壞

來源

2011-03-13 04:29:09 Tim

，不使用專門的API，你應該假設任何能夠讀取硬盤的人都可以讀取內存中的任何文本，並且任何能夠讀取您內存的人（例如root或同等身份，來自同一用戶的另一個進程或進程中的漏洞利用程序）都可以讀取。

您的內存可能會被分頁到磁盤。某些環境有專門的分配內存的方式來防止分頁（我不知道C＃標準庫中是否有這樣的設備，但我認爲可以在Windows上使用這種設備）。

來源

2011-03-13 04:30:50 rlibby

是否有其他選擇提示用戶輸入SQL服務器的憑據？我並不想讓最終用戶知道這些信息，所以我寧願在程序中對SQL連接字符串進行硬編碼。雖然，看到crack.net讓我擔心有人可以很容易地拉那個字符串。也許這超出了我的程序範圍，我應該說「我們應該審計該賬戶的數據庫連接」，但這感覺就像是一個警察。 – 2011-03-13 15:29:32

@Jeff Plott，我不太瞭解SQL Server，所以我沒有資格在這裏給你提供建議。但是，如果您的問題是身份驗證，那麼一般來說，是的，有幾種方法可以要求用戶名和密碼。一個例子是Kerberos。 – rlibby 2011-03-13 21:06:18

如果要將字符串加載到內存安全中，請使用SecureString類http://msdn.microsoft.com/en-us/library/system.security.securestring.aspx。另請參見：http://www.vcskicks.com/secure-string.php

來源

2011-03-13 04:34:48

並不安全可言，即使內存保護是微不足道的只是把內存轉儲或使用類似Crack.net偷看到內存中。

您可以使用System.Security.SecureString這是一個有點痛苦地工作着，但「代表應當保密的文字。文字進行加密，隱私在使用時，從計算機內存中刪除不再需要的。」

來源

2011-03-13 05:29:40

+1，儘管許多.NET API只接受普通的System.String :( – 2011-03-13 10:06:26

的確如前所述，SecureString是一個很難使用的工具，並且需要完整的端到端的使用（相對於完全在SecureString和String之間進行轉換）擊敗目的） – 2011-03-13 10:09:23

東西存儲在內存中有多安全？

回答

相關問題