【问题标题】:File.Delete or File.Encrypt to wipe files?File.Delete 或 File.Encrypt 擦除文件?
【发布时间】:2019-06-29 07:21:49
【问题描述】:

是否可以使用 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

【问题讨论】:

  • 我认为不赞成票的原因可能是这种情况存在一个更根本的问题,即以纯文本形式存储凭证而不考虑推理通常是一个非常糟糕的主意。也就是说,如果您想摆脱它,只需使用File.Delete。你能解释一下你为什么考虑使用File.Encrypt吗?提供一些关于为什么凭证存储为纯文本的上下文也可能会有所帮助,因为这可能暗示了一个更简单的幕后问题。
  • File.Encrypt 对文件进行加密,因此库中可能有一些特殊处理来清除明文。所以我可以做File.Encrypt(path); File.Delete(path)。是的,我也知道以明文形式存储凭据是不好的,但我不明白为什么人们只想让这些问题保持沉默……改变这一点并不总是由你决定,甚至可能有很好的理由是这样的……
  • File.Delete 会将明文保留在磁盘上的某个位置。在 SSD 上也可以覆盖它。也许使用 File.Encrypt 并不太疯狂。
  • 我不太确定File.Encrypt 是否真的将明文从磁盘上切掉了。它在逻辑层面已经到位,但它的内部实现并没有对物理层面做出任何承诺。特别是在 SSD 上,没有办法真正确保内容被擦除。我会考虑用垃圾覆盖文件(不要费心加密,只要随机或零就可以了),你就完成了,尽可能多。

标签: c# .net .net-standard-2.0


【解决方案1】:

File.Encrypt 有可能比 File.Delete 更有助于粉碎数据(在这方面肯定没有任何作用),但这不是一种可靠的方法。

在操作系统和硬件级别上都发生了很多事情,即从 .NET 代码中分离出来的几个抽象层。例如,您的文件系统可能会随机决定移动它在磁盘上物理存储文件的位置,因此覆盖您当前认为文件所在的位置可能实际上不会从之前存储文件的位置删除痕迹。即使您成功覆盖了文件的正确部分,磁盘本身也经常存在残留信号,可以被使用正确设备的人拾取。一些文件系统并没有真正覆盖任何东西:它们只是在每次发生更改时添加信息,因此您可以随时了解磁盘在任何给定时间点的内容。

因此,如果您合法地无法阻止文件被保存,那么任何真正擦除它的尝试都是不完美的。如果您愿意接受不完美并且只想在一定程度上减轻潜在的问题,您可以使用策略like the ones you've found 尝试用垃圾数据多次覆盖文件并希望获得最好的结果。

但我不会很快放弃从源头上解决问题。例如,Ansible's docs 提及:

如果您不需要在每个主机上生成随机密码,那么密码查找插件的一个很好的替代方法是在 playbooks 中使用 Vault。阅读那里的文档并考虑先使用它,这对于大多数应用程序来说会更理想。

【讨论】:

  • 这是关于 ansible 内部的。我将添加有关明文凭据的确切保存位置的部分内容。
  • 老实说,我对 Ansible 一无所知,因此我可能无法谈论这些细节,但我确实注意到您链接到的代码位于带有“Legacy”的文件中以它的名义,所以也许有一种更新、更好的方法来做你想做的事情?也许这可能是一个单独的 StackOverflow 问题。
  • 我只是想提供一些上下文,但你是对的,这超出了这个问题的范围。也许有人对这个问题有完美的解决方案,但目前看来,走不完美的路线是目前最好的,从长远来看,找到一种从不保存文件的方法是最好的。
猜你喜欢
  • 2020-11-27
  • 1970-01-01
  • 2023-03-13
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-10-19
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多