Introduction
DPAPI stands for Data Protection API. It is a component in Windows operating systems which can provide symmetric encryption of any kind of data. It is the generally recommended approach for securing locally stored data, including credential information and cryptographic keys. It is used by many applications for this, including Chrome and SQL Server. A major advantage of it is that key management is taken care of by Windows.
DPAPI is accessible in .NET. It can offer convenient and inexpensive secure application-level encryption. However misusing it can result in security issues, problems decrypting data or irretrievable data. Therefore it is important to have some understanding of how it works and to be aware of requirements for it to be used safely.
Overview
DPAPI has two forms: Machine-level and user-level. Data encrypted using machine-level DPAPI can only be decrypted on the same machine (but under any account). Data encrypted using user-level DPAPI can only be decrypted under the same account (but on any machine). User-level encryption is generally more secure and allows wider applications than machine level encryption, but can also have problems if it is misused.
User-level DPAPI works by generating a MasterKey from the user’s password. It stores this in the user’s profile, and uses this in conjunction with other secrets to create cryptographic keys. New MasterKeys are generated after periods of time, in line with an effective key management strategy.
Requirements for Safe User-level DPAPI
I’m aware of the following requirements for using user-level DPAPI safely in .NET. If it looks like I’ve left anything out then please add a comment…
- Roaming profiles should be used so that the machine is not a point of failure.
- The LoadUserProfile flag in the application pool needs to be set to true to allow user level encryption.
- Mandatory profiles can’t be used for user level encryption because they are read-only.
- The profile should only be used on one machine at a time. Concurrent logins on different machines can result in problems decrypting data. (Therefore DPAPI is unsuitable for data that needs to be encrypted/decrypted on more than one machine at a time.)
- Profiles need to be backed up. If the profile is deleted or corrupted and cannot be recovered then the encrypted data may be irretrievably lost.
- Keys are backed up by the domain controller. If the profile is unable to use a MasterKey it needs then it can securely retrieve the MasterKey from the domain controller. (That means that keys generated since the last backup will not be lost in the event of a restored profile. It only seems to be important that the profile is not lost entirely.)
- In workgroup or standalone PCs administrator should not reset the profile password as this will lead to the encrypted data not being recoverable. Password reset disks can be used to safely reset the password. Obviously these themselves need to be secured. In domain PCs the keys are automatically updated as per the process described in the previous point.
I plan to add a follow-up post where I’ll describe how user-level DPAPI can be used to encrypt secrets needed by source code as part of the deployment process.
Source Material and Further Reading
https://support.microsoft.com/en-us/help/309408/how-to-troubleshoot-the-data-protection-api-dpapi
https://msdn.microsoft.com/en-us/library/ms995355.aspx#windataprotection-dpapi_topic02a
https://cheatsheetseries.owasp.org/cheatsheets/DotNet_Security_Cheat_Sheet.html