是否可以使用File.Delete或File.Encrypt来粉碎文件？还是这两个功能都不会覆盖磁盘上的实际内容？ 并且如果这样做的话，这是否也适用于ssd的耗损均衡以及其他存储的类似技术？还是我应该使用另一个功能？
我正在尝试改进一个开放源代码项目，该项目当前将凭证以明文形式存储在文件中。由于它们总是被写入该文件的原因（我不知道Ansible为什么这样做，但是现在我不想触及代码的那部分，可能有一些合理的原因，为什么是这样，至少现在），然后我可以删除该文件。那么使用File.Delete或File.Encrypt是从磁盘清除该信息的正确方法吗？
编辑：如果只能使用本机API和pinvoke，我也可以。我不仅限于.net，还限于C＃。
Edit2：提供一些上下文：纯文本凭据由ansible内部保存，因为它们作为在目标Windows主机上执行的模块的变量传递。该文件负责再次检索变量：https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/powershell/Ansible.ModuleUtils.Legacy.psm1#L287 https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/csharp/Ansible.Basic.cs#L373
答案 0 :(得分：1)
File.Encrypt有可能比File.Delete（在这方面绝对没有作用）在帮助粉碎数据方面做更多的工作，但这不是可靠的方法。
在操作系统和硬件级别上都有很多工作，这是与.NET代码分开的几个抽象层。例如，您的文件系统可能会随机决定将其实际存储文件的位置移动到磁盘上，因此覆盖您当前认为文件所在的位置实际上可能不会删除先前文件存储位置的痕迹。即使您成功覆盖了文件的正确部分，磁盘上通常也会残留一些信号，这些信号可能会被配备了正确设备的人拾取。某些文件系统并不能真正覆盖任何内容：它们只是在每次发生更改时添加信息，因此您始终可以找出磁盘在任何给定时间点的内容。
因此，如果您不能合法地防止文件被保存，则真正删除文件的任何尝试都将是不完美的。如果您愿意接受不完善之处，而只想在某种程度上减轻问题的可能性，则可以使用策略like the ones you've found尝试用垃圾数据覆盖文件几次，并希望达到最佳效果。
但是我不会太急于放弃从根本上解决问题。例如，Ansible's docs提及：
如果您不需要按主机生成随机密码，那么密码查找插件的一种很好的替代方法是在剧本中使用保险柜。阅读那里的文档，并考虑先使用它，对于大多数应用程序来说，这将是更理想的选择。