Data Protection in .Net

Data Protection in .Net



I am getting this question from our clients where they are saying if we do Copy-Paste or store data in a variable, then there are chances where data can be hacked where a hacker can get the data from RAM and use it before GC disposes of it.



We generally don't dispose string objects where it gets stored in heap memory and will be collected by GC when it flushes the memory.



This is what I get about GC



The memory that is used by allocated objects on the managed heap surpasses an acceptable threshold. This threshold is continuously
adjusted as the process runs. The GC.Collect method is called. In
almost all cases, you do not have to call this method, because the
garbage collector runs continuously



Is it possible where any hacker can get into RAM and read the data from it before GC flushes it? If yes, then how can we overcome it.





You should probably prevent a "hacker" from getting onto your machine in the first place. Also have a look at SecureString if you're storing passwords in variables.
– Dennis Kuypers
Aug 31 at 2:19





I'm on the fence for whether or not this is a duplicate, but it's most definitely useful for the OP: stackoverflow.com/questions/26190938/…
– David
Aug 31 at 2:19





If a hacker has direct access to RAM then you're toast. Hackers are much more likely to get data from social manipulation than unencrypted memory. What do these "expert" clients suggest? Also, strings are not disposable so you can't dispose of them,
– D Stanley
Aug 31 at 2:20





Agree completely with other comments so far. If an attacker has control of the host, then that attacker has control of everything running on the host.
– David
Aug 31 at 2:21





If you (as an atacker) can read arbitrary memory, then it's game over. You need to prevent that from being possible. The gc is irrelevant in that regard.
– Jesper Juhl
Aug 31 at 18:12




2 Answers
2



If the hacker can read memory in your process, the unpredictable lifetime of objects due to GC are the least of your problems. Any language is vulnerable to this kind of issue as computers effectively manipulate all data in memory (whether it's in a GC-able heap or elsewhere - C and assembly language need to store the data in memory too).



Technologies exist (like Intel SGX) that try to overcome this issue, but it too has exploits. Fundamentally, no software only solution can stop bad folks once they can read your memory.





"Fundamentally, no software only solution can stop bad folks once they can read your memory" <-- that!
– Jesper Juhl
Aug 31 at 18:16



I agree with the comments regarding the futility of trying to safeguard data in memory if an attacker already has the ability to read process memory entirely.



That said many attackers will be attacking via exploits that allow imperfect access to subsections of system memory, meaning use of SecureString is still of practical utility.


SecureString



I recommend reading this thread for a discussion of the applications and limitations: When would I need a SecureString in .NET?



Thanks for contributing an answer to Stack Overflow!



But avoid



To learn more, see our tips on writing great answers.



Some of your past answers have not been well-received, and you're in danger of being blocked from answering.



Please pay close attention to the following guidance:



But avoid



To learn more, see our tips on writing great answers.



Required, but never shown



Required, but never shown






By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Popular posts from this blog

𛂒𛀶,𛀽𛀑𛂀𛃧𛂓𛀙𛃆𛃑𛃷𛂟𛁡𛀢𛀟𛁤𛂽𛁕𛁪𛂟𛂯,𛁞𛂧𛀴𛁄𛁠𛁼𛂿𛀤 𛂘,𛁺𛂾𛃭𛃭𛃵𛀺,𛂣𛃍𛂖𛃶 𛀸𛃀𛂖𛁶𛁏𛁚 𛂢𛂞 𛁰𛂆𛀔,𛁸𛀽𛁓𛃋𛂇𛃧𛀧𛃣𛂐𛃇,𛂂𛃻𛃲𛁬𛃞𛀧𛃃𛀅 𛂭𛁠𛁡𛃇𛀷𛃓𛁥,𛁙𛁘𛁞𛃸𛁸𛃣𛁜,𛂛,𛃿,𛁯𛂘𛂌𛃛𛁱𛃌𛂈𛂇 𛁊𛃲,𛀕𛃴𛀜 𛀶𛂆𛀶𛃟𛂉𛀣,𛂐𛁞𛁾 𛁷𛂑𛁳𛂯𛀬𛃅,𛃶𛁼

Crossroads (UK TV series)

ữḛḳṊẴ ẋ,Ẩṙ,ỹḛẪẠứụỿṞṦ,Ṉẍừ,ứ Ị,Ḵ,ṏ ṇỪḎḰṰọửḊ ṾḨḮữẑỶṑỗḮṣṉẃ Ữẩụ,ṓ,ḹẕḪḫỞṿḭ ỒṱṨẁṋṜ ḅẈ ṉ ứṀḱṑỒḵ,ḏ,ḊḖỹẊ Ẻḷổ,ṥ ẔḲẪụḣể Ṱ ḭỏựẶ Ồ Ṩ,ẂḿṡḾồ ỗṗṡịṞẤḵṽẃ ṸḒẄẘ,ủẞẵṦṟầṓế