[Mono-bugs] [Bug 44848][Wis] Changed - Zeroize data upon GC collect

[bugzilla-daemon@rocky.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by lupus@ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=44848

--- shadow/44848	Sun Jun 15 15:36:57 2003
+++ shadow/44848.tmp.3439	Tue Jun 17 10:18:28 2003
@@ -1,13 +1,13 @@
 Bug#: 44848
 Product: Mono/Runtime
 Version: unspecified
 OS: All
 OS Details: 
-Status: NEW   
-Resolution: 
+Status: RESOLVED   
+Resolution: WONTFIX
 Severity: Unknown
 Priority: Wishlist
 Component: misc
 AssignedTo: mono-bugs@ximian.com                            
 ReportedBy: spouliot@videotron.ca               
 QAContact: mono-bugs@ximian.com
@@ -46,6 +46,22 @@
 GC.MarkSensitiveData (object o) which would mark an object as
 "sensitive", meaning that when it was deallocated that it would
 automatically zeroized. Then, we could call GC.Collect () in the place
 where the api needs to zeroize sensitive data. This method would have
 the advantage that only data that was marked as sensitive would be
 zeroized, meaning that the performance hit would be even smaller.
+
+------- Additional Comments From lupus@ximian.com  2003-06-17 10:18 -------
+zeroing data on collect would have a huge performance impact.
+There's more: doing it on collect means a lot of time may pass with
+the sensitive data still in memory, possibly until program termination.
+So I don't how it would help. You can get the same effect by storing
+the sensitive data in an object those class defines a destructor that
+clears the data: this at least affects the performance of the security
+code only and not of all the runtime. The real solution is to clear
+the data as soon as possible manually (or with the Dispose()/using
+pattern) and never ever using strings to hold sensitive info, since
+strings are immutabled, they can't be cleared. Manual zeroing requires
+you know where the sensitive data lifetime and that you don't pass
+around references to it to unknown code: I think this is a fair
+assumption to make in code where sensitive data is used.
+