c# - How secure is ProtectedData.Protect (DPAPI)?

Question

Suppose someone gets access all of my hard disk, I guess the weak spot would be my windows password. Without knowing/being able to retrieve that, the data should be pretty much safe, shouldn't it?

I'm asking specifically because of the EFS entry in wikipedia which states that

In Windows 2000, the local administrator is the default Data Recovery Agent, capable of decrypting all files encrypted with EFS by any local user.

and EFS happens to use DPAPI. So does the same apply to my own data protected using this:

ProtectedData.Protect(plain, null, DataProtectionScope.CurrentUser);

And if that is indeed the case, how could I prevent it?

[Edit] N.B. I'm trying to store credentials for a winforms app so that the user does not have to enter their password every time they login. In other words, if someone is able to login as that user (i.e. know the user password), then they might as well be able read the encrypted data.

Which - not coming from a windows background - now makes me wonder - can't the local admin login as any local user anyway? In that case I shouldn't be concerned about the admin being able to retrieve passwords anyway...

[Edit2] As google reveals, it looks like an Administrator cannot just login as any user without resetting/changing their password first. So my question still seems relevant...

Answer 1

EFS uses DPAPI, not the other way around. And Administrator can't read your key just like that.

Before forgetting about DPAPI, I would consider the alternatives. If you encrypt the file yourself,

1. You must select a strong algorithm and implement it well.
2. You will need a key. Where will it be ?
3. You will store the key in a file somewhere on your drive.
4. That key is sensitive, obviously, you will want to encrypt it
5. Goto 1

DPAPI does 1 to 3 well. 4 and 5 are moot. If a Windows password is not enough to protect data, ask yourself why it is enough to CRUD that data in the first place.

For better security, you can consider not saving the data but a (salted) hash of it, if possible. It makes your data write only, though. For example, if you want to verify a customer license number :

• Save a salted hash value of it
• Run the same hash on the salted license number you want to verify,
• Compare the two. It they match, the license is valid.

If you must read back encrypted data and a locally encrypted key is not enough, consider encrypting your application key (step 2 above) with a private key stored on a smart card.

Either way, remember that things happens. You always need a backup key somewhere.