3、关于视窗操作系统“连接登录”对话框问题
原因在于视窗操作系统对这类密码解码及研判，既没有如“用户登录”对话框般采用比较安全的“OpeNPassworDCachE”方法对有关内存进行分配，也没有对有关密码存储的内存在研判后进行必要“清零”。所以我们可以轻而易举地通过内存探查，找到用户的上述敏感数据。
对策：
首先考虑启用较安全的“OpeNPassworDCachE”方法对有关内存进行分配，并确保密码比较后必须立即执行有关密码内存单元的 “清零”工作，以抵御内存探查工具“窥视”攻击。如果需要更安全的密码研判，就应该尽可能避免在内存里出现明文密码，具体做法请参考我们完成的《脆弱的软件著作权保护方式及对策》一文，里头相应地给出一个有效的解决方案。
4、关于视窗操作系统“共享登录”设置对话框问题
原因在于视窗操作系统对这类密码解码及研判，既没有采用比较安全的“OpeNPassworDCachE”方法对有关内存进行分配，也没有对有关密码存储的内存在研判后进行必要“清零”。所以我们可以轻而易举地通过内存探查，找到用户的上述敏感数据。
对策：
首先考虑启用较安全的“OpeNPassworDCachE”方法对有关内存进行分配，并确保密码比较后必须立即执行有关密码内存单元的“清零”工作，以抵御内存探查工具“窥视”攻击。如果需要更安全的密码研判，就应该尽可能避免在内存里出现明文密码，具体做法请参考我们完成的《脆弱的软件著作权保护方式及对策》一文，里头相应地给出一个有效的解决方案。
三、结论
对于被具有起码强度的稳健单向HasH算法保护的产品，简单并可能有效但是未必高效的攻击当然首先考虑的是穷举，当然其规模不能太大，但是对于视窗操作系统产品而言，在大多数情况下就连穷举都可以省略，直接“Crack”或直接进行内存探查就能达到目的，这是因为其没有对系统指令代码及密码等敏感数据所在内存的安全性进行必要的维护以及保护：
（1）对于系统指令代码而言，视窗操作系统大都以常规形式读写、执行，缺乏对关键指令代码进行必要的校验，以防止其在系统内存里被“篡改”。
（2）对于密码数据而言，视窗操作系统将“还原”后的密码在“使用”完毕后仍以明码形式遗留在系统内存里，而“密码存储内存在密码研判后进行清零”——这是稍有些密码安全知识的人的常识性做法，何以视窗操作系统生产商却出现如此疏忽？
目前我们尚未获得视窗操作系统生产商在其本土销售的版本，如果相关的分析表明仅仅在其国际版本里才存在本文讨论的这些密码安全体系弱点，抛开其开发成本或稳定性等托词，其真正用意值得大家深思。
大家也不要认为视窗2K等版本相对而言较安全，就抱着侥幸心理以为没有上述有关密码安全体系方面的弱点。我们的分析包括了视窗2K等版本，就“用户登录”对话框问题而言，视窗2K等版本操作系统同样存在上述安全隐患。只需对一个名为“■sv1_0”的系统动态链接库文件，仅仅修改其“一个”字节后，视窗2K等版本操作系统起码的安全环节就告失效。可轻松以超级用户“Administrator”登录，利用这个弱点无须“Crack”，有关的“时间成本”几乎为零！所以本文的讨论还是有代表性的。希望能引起大家必要的重视。
视窗2K版本的相关实验：
在视窗2K版本操作系统内找到名为“■sv1_0”的系统动态链接库文件，然后在常见的十六进制编辑器里搜索十六进制串{ F8 10 0F 84 71 FF FF }后将其间的{ 10 }改为{ 00 }即上述十六进制串被改动一个字节后变为{ F8 00 0F 84 71 FF FF }，即：
搜索 → F8 10 0F 84 71 FF FF
替为 → F8 00 0F 84 71 FF FF
保存这个改动，然后尝试以超级用户“Administrator”登录，就会发现相关的密码安全弱点。
对策：
这个例子所揭示的安全弱点的有关对策请参考我们完成的《脆弱的软件著作权保护方式及对策》一文，里头有更为详尽的分析。
事实证明，对于不借助可热插拔的移动存储介质保存密码（密钥）以及缺乏稳健的密码安全体系的视窗操作系统，目的明确并具备起码专业技能的人员“入侵”视窗操作系统并不是一件困难的事情。（作者单位 Abusys公司）
