-3

is it possible to use either File.Delete or File.Encrypt to shred files? Or do both functions not overwrite the actual content on disk? And if they do, does this also work with wear leveling of ssds and similar techniques of other storages? Or is there another function that I should use instead?

I'm trying to improve an open source project which currently stores credentials in plaintext within a file. Because of reasons they are always written to that file (I don't know why Ansible does this, but for now I don't want to touch that part of the code, there may be some valid reason, why that is that way, at least for now) and I can just delete that file afterwards. So is using File.Delete or File.Encrypt the right approach to purge that information off the disk?

Edit: If it is only possible using native API and pinvoke, I'm also fine with that. I'm not limited to only .net, but to C#.

Edit2: To provide some context: The plaintext credentials are saved by the ansible internals as they are passed as a variable for the modules that get executed on the target windows host. This file is responsible for retrieving the variables again: 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

K. Frank
  • 1,325
  • 1
  • 10
  • 19
  • 1
    I think the reason for the downvotes is probably that there is a more fundamental issue with this scenario in that the storage of credentials in plain text regardless of reasoning is generally a very bad idea. That said, if you want to get rid of it just use `File.Delete`. Can you explain why you thought about using `File.Encrypt`? It might also be helpful to provide some context as to why the credentials are stored plain text as this might allude to a simpler issue behind the scenes. – Dillanm Jun 28 '19 at 22:11
  • File.Encrypt encrypts the file in place, so maybe there is some special handling within the library to also purge the plaintext. So I could do `File.Encrypt(path); File.Delete(path)`. And yes I also know that storing credentials in plaintext is bad, but I don't understand why people just want to silence those questions... It is not always up to you to change that, and there may even be good reasoning why that is how it is... – K. Frank Jun 28 '19 at 22:15
  • 1
    File.Delete will leave the plaintext somewhere on the disk. Overwriting it may too, on an SSD. Maybe it’s not too crazy to use File.Encrypt. – John Wu Jun 28 '19 at 22:33
  • I'm not so sure that `File.Encrypt` actually shreds the plaintext off disk. It's in place, at the logical level, but its internal implementation doesn't promises anything about the physical level. And specially on SSDs, there is no way to actually ensure that the content is wiped. I would consider overwriting the file with garbage (don't bother to encrypt, just random or zeros will do) and you're done, as much as you can. – Alejandro Jun 28 '19 at 22:37
  • Possible duplicate: https://stackoverflow.com/q/1046635/120955 – StriplingWarrior Jun 28 '19 at 22:41
  • What is the most I can do to overwrite the file? I've looked around github for some file shredders, they did a streamwriter with garbage, updated file times and than renamed the file a few times. Is that all I can do? This looks very unreliable... – K. Frank Jun 28 '19 at 22:42

1 Answers1

1

There's a possibility that File.Encrypt would do more to help shred data than File.Delete (which definitely does nothing in that regard), but it won't be a reliable approach.

There's a lot going on at both the Operating System and Hardware level that's a couple of abstraction layers separated from the .NET code. For example, your file system may randomly decide to move the location where it's storing your file physically on the disk, so overwriting the place where you currently think the file is might not actually remove traces from where the file was stored previously. Even if you succeed in overwriting the right parts of the file, there's often residual signal on the disk itself that could be picked up by someone with the right equipment. Some file systems don't truly overwrite anything: they just add information every time a change happens, so you can always find out what the disk's contents were at any given point in time.

So if you legitimately cannot prevent a file getting saved, any attempt to truly erase it is going to be imperfect. If you're willing to accept imperfection and only want to mitigate the potential for problems somewhat, you can use a strategy like the ones you've found to try to overwrite the file with garbage data several times and hope for the best.

But I wouldn't be too quick to give up on solving the problem at its source. For example, Ansible's docs mention:

A great alternative to the password lookup plugin, if you don’t need to generate random passwords on a per-host basis, would be to use Vault in playbooks. Read the documentation there and consider using it first, it will be more desirable for most applications.

StriplingWarrior
  • 151,543
  • 27
  • 246
  • 315
  • It's about ansible internals. I'll add a part about where exactly the plaintext credentials are saved. – K. Frank Jun 28 '19 at 22:59
  • I honestly don't know anything about Ansible, so I probably won't be able to speak to those details, but I do notice that the code you linked to is in a file with "Legacy" in its name, so maybe there's a newer, better way to do what you're trying to do? Perhaps that could be a separate StackOverflow question. – StriplingWarrior Jun 28 '19 at 23:16
  • 1
    I just wanted to provide some context, but you're right, that is out of scope for this question. Maybe someone has the perfect solution for this problem, but currently it looks like going the imperfect route is the best for now and finding a way to never save the file in the first place is the best in the long term. – K. Frank Jun 28 '19 at 23:32