Summary: unless you have very specific requirements, just use the decent tools Microsoft has provided.
DPAPI allows you to encrypt with user specific or computer specific keys. On a typical shared machine it is slightly less safe to store data for one user in computer context.
If your WinPE environment is short lived, e.g. the tool runs and then it shuts down, it should be quite safe to use “current computer” mode. You can do this by setting dwFlags
to CRYPTPROTECT_LOCAL_MACHINE
when calling CryptProtectData
.
At this point your secret data is stored on disk using encryption which should be well implemented and tested by Microsoft. This is better than rolling your own crypto.
Risks now are:
- Anybody who can run code on the machine can extract the secret. If this is a concern, also pass a value for
pOptionalEntropy
to CryptProtectData
. This is effectively a “password” and would force an attacker to also reverse engineer your program to obtain the additional entropy. However, if someone can run code it should be game over for most sensible threat models.
- Data can be obtained from a forensic image of the machine. Offline decryption of DPAPI data is possible, there are tools and even a Python implementation. However, this takes time and requires a good forensic image of the original PC. Note it is not an offline attack, you need all of the key material. This is no different to using any other encryption to protect the data. Consider Bitlocker to protect the disk.
If you control the web application, also consider best practises like risk scoring API token usage. Has the client IP changed? Has the bowser changed? Is the client trying to conduct a privileged operation? Each of these can increase a risk score and perhaps trigger extra validation.