The Windows Data Protection API (DPAPI) is the suggested method for storing secrets on Windows systems (such as database passwords required by ASP.Net applications).

DPAPick was presented at BlackHat DC 2010 and WOOT'10, with a focus on recovering past passwords and encrypted file system certificates. The presentation abstract claims decryption of all DPAPI encrypted data. Since it is an offline attack Windows registry access controls are also ineffective.

What are the limitations on DPAPick's effectiveness and how can its blindspots and weaknesses be exploited to better protect data I am storing on workstations for my applications?

  • This is... shocking, to say the least. I'm definitely going to be trying another few times to really understand that paper... But in the meantime, we're back at looking for a solution?? @Bell, thanks for the headsup on this.... – AviD Feb 22 '11 at 21:54
  • DPAPick itself, last I heard, didn't do windows 7, etc. But I wouldn't rely on that lasting long - I'd focus on what the reverse engineering has revealed about blindspots and weaknesses in how Windows is storing stuff. – nealmcb Feb 26 '11 at 4:11
  • Related: Enumerating the keys in RSACryptoProvider – random65537 Sep 29 '11 at 4:33
up vote 11 down vote accepted

@nealmcb asked me (Thanks!) about this and this is indeed a great question that is not covered in our paper. I agree that we are not giving enough advice about how to deal with DPAPI security. I will fix this by writing a blog post but in the meantime here is an overview of what you can do:

Overall DPAPI is a blackbox API that allows you to tie any secret data, such as the firefox passwords database, to a windows account password. To decrypt any DPAPI secret you need a hash of the user password (in SHA1 (16_LE) not NTLM though).

So in an offline attack setting an attacker first needs to brute force (or guess) the user password to get this hash, so a "strong" password is definitely the first good line of defense. But remember that we have rainbow tables for NTLM so DPAPI security is also affected by this.

Disk encryption such as bitlocker and truecrypt are a good first line of defense against this because the attacker obviously needs to decrypt the hard drive before attempting to recover the DPAPI data.

What is not a good idea is believing that EFS will solve the problem, because the certificates needed to decrypt the file are encrypted with a "DPAPI" like system. So once the user password is known, all the attacker has to do is first decrypt the EFS files by recovering the certificate and then decrypt the DPAPI data.

I hope this clarifies the situation. For the CREDHIST problem, I am thinking of writing a tool that clears it (at least the first N old passwords).

Let me know if you have other questions

  • I've been looking at EFS to provide an comment on SteveS's answer and I see the following limitations or requirements: If the whole system drive is encrypted (pre OS boot) it will protect DPAPI data in the registry and prevent the brute-force or rainbow against the passwords. If the EFS solution manages volumes after boot then it leaves attacks on the passwords open and any DPAPI protected data needs to be stored in a file on the EFS rather than in the registry. The whole file system may also be vulnerable, depending on how it manages its certificates. Does that sound correct? – Bell Mar 1 '11 at 18:35
  • If LM hashes simplify the attack then suppressing their generation as per should also help. – Bell Mar 1 '11 at 19:06
  • I'm not really understanding how this is a security flaw. If you already have the user password and a copy of the encrypted data and know how the algorithm works, shouldn't you be able to crack any scheme? – Casebash Jul 27 '11 at 4:18
  • I agree with @Casebash : if you have the password, access the data using CryptUnprotectData in a custom data extraction tool if needed. It is nice to have DPAPI reversed engineered, though. – ixe013 Aug 4 '11 at 19:03

This is mainly a reverse engineering of the algorithm, since the API employed security by obscurity and didn't provide a full set of primitives.

So it seems that this first of all amplifies the need to use a really a good login password, resistant to dictionary attacks.

Also never use a weak password since it will expose your other ones to easy cracking.

Always be alert for the possibility of a backdoor, as described in the paper: Elie - Reversing DPAPI and Stealing Windows Secrets Offline.

And lobby Microsoft to accept the offer from the more qualified crypto folks who did this free analysis for them. I.e. fix their broken CREDHIST mechanism. Or switch to another secret storage scheme....

I give you exhibit A, a PC with an installed Windows operating system, and a configured user account, and some data which has been "protected" with DPAPI on behalf of the user.

Then exhibit B, the user himself.

We place the two entities together in a room, with some electrical power but no external network. The user B powers machine A up, then proceeds to type his password and log on. And then user B accesses the protected data.

Therefore, the integral contents of the machine state (i.e. its hard disk) and the knowledge of the user's password are sufficient to recover the data. Corollary: if an attacker can get his hands on the machine state (e.g. he stole the whole laptop), then he can run an offline dictionary attack on the user's password, which he can make arbitrarily fast by throwing more hardware at it.

The rest is just the usual circus of security by obscurity, reverse engineering, and uttering a long stream of serious-looking acronyms to exorcise the threat of Evil Hackers™. The offline dictionary attack situation can be mitigated by the usual password hashing bells and whistles (see bcrypt). A more thorough approach would use a tamper-resistant device, e.g. an external smart card, or a TPM, which conceptually deprives the attacker of a crucial part of the machine state; but this is more expensive and has impacts on data recovery in case of hardware failure.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.