.NET Framework 中的安全性支持在版本 2.0 中备受关爱，本月我将带您快速浏览在其中发现的引人之处。我不会讨论所有内容，但您将会了解从哪里开始查看，并在哪里停留以查看新的变化。我每次讨论一个命名空间。对了，要提出这样显而易见的警告：这是测试版软件，所以我这里讲述的所有内容在最终版本发行之前都有可能更改。
System.Security
托管字符串对机密内容来说并不是好的存储媒体。的确没有办法删除一个。垃圾回收对改写所收集的内存没有任何担保，在很多情况下，在由堆压缩进行改写之前，成为垃圾的字符串仍会在托管堆中保留一段时间。并且，垃圾回收器可能会在托管堆中到处移动它们。将其与不能将旧内存清零的事实结合起来，您可能会终止地址空间中您试图保存机密的许多字符串实例。引入了一个新类 SecureString 来帮助解决这些问题。
该类使用数据保护 API (DPAPI) 保护的内存模型存储其数据。换句话说，数据总是以其加密的形式存储在 SecureString 内。密钥是由本地安全性授权子系统 (LSASS.EXE) 通过 DPAPI托管的，这些数据可以通过进程间通信解密。
为了使该类更加有效，任何读取机密数据（可能是来自控制台的密码，也可能是来自 Web.config 的连接字符串）的 .NET Framework 方法都需要直接封装 SecureString 中的数据并将它返回给您。您不能仅通过用 SecureString来包装普通字符串，就期望会更加安全 — 为了更加有效，不能在一个普通托管字符串中放置机密内容。
同样的规则也适合于将机密返回给 .NET Framework。例如，ProcessStartInfo 中的 Password 新属性（随后将讲到）是 SecureString 类型的。在内部，当需要机密数据时，.NET Framework 将通过 Marshal.SecureStringToBSTR 等新函数使用 Marshal 类来检索机密数据的实际内容。因为 Marshal 类是在非托管内存中处理的，所以当框架使用结束后，可以将这些内存正确地清零。毫无疑问，您不能使用 ToString 来检索来自 SecureString 的机密。记住，永远不能将机密数据最终保存在普通字符串对象中。
但是我弄不明白的一件事就是在交换文件之外保守机密的方法。当机密数据未进行封送处理就进入本机内存时，我想没有什么办法可以保证未进行封送处理的页面可以通过 VirtualLock 进行锁定。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
