相关疑难解决方法(0)

如果我的假设在这里错了,请随意纠正我,但让我解释一下我为什么要问.

摘自MSDN,a SecureString:

代表应保密的文本.文本在使用时加密以保护隐私,并在不再需要时从计算机内存中删除.

我明白了,将密码或其他私人信息存储在a中是完全合理SecureString的System.String,因为你可以控制它实际存储在内存中的方式和时间,因为System.String:

是不可变的,当不再需要时,不能以编程方式安排垃圾收集; 也就是说,实例在创建后是只读的,并且无法预测实例何时从计算机内存中删除.因此,如果String对象包含敏感信息(如密码,信用卡号或个人数据),则使用该信息后可能会显示该信息,因为您的应用程序无法从计算机内存中删除该数据.

但是,在GUI应用程序(例如,ssh客户端)的SecureString 情况下,必须从a构建 System.String.所有文本控件都使用字符串作为其基础数据类型.

因此,这意味着每次用户按下某个键时,就会丢弃那里的旧字符串,并构建一个新字符串来表示文本框内的值,即使使用密码掩码.并且我们无法控制何时或是否从内存中丢弃任何这些值.

现在是时候登录服务器了.你猜怎么着？您需要在连接上传递一个字符串以进行身份验证.所以让我们将我们SecureString转换为System.String....现在我们在堆上有一个字符串,无法强制它通过垃圾收集(或将0写入其缓冲区).

我的观点是:无论你做什么,沿线某处,那SecureString是会被转换成一个System.String,这意味着它至少会在某些点上堆存在(没有垃圾收集的任何保证).

我的观点不是:是否存在绕过将字符串发送到ssh连接或绕过控件存储字符串(制作自定义控件)的方法.对于这个问题,您可以将"ssh connection"替换为"登录表单","注册表单","付款表单","食物 - 你愿意喂你的小狗但不是你孩子的表格",等等

那么,在什么时候使用SecureString实际变得实用？
是否值得花费额外的开发时间来彻底根除System.String对象的使用？
完全重点是SecureString减少System.String堆上的时间(降低转移到物理交换文件的风险)？
如果攻击者已经拥有进行堆检查的手段,那么他很可能(A)已经有了读取击键的方法,或者(B)已经在物理上拥有该机器 ...所以会使用a SecureString阻止他进入数据呢？
这只是"通过默默无闻的安全"吗？