Can't find anything online about a fix from Microsoft (didn't give it much effort - little pressed for time), but it seems that decryption is possible because the master key timestamp isn't protected by an HMAC mechanism (perpetuating access to the secret). Also, all the user's previous SHA1 hashes aren't salted.
Both of those seem easy enough to fix, which I imagine Microsoft has done (the exploit was discovered 3 years ago). I'm going to do a little more research when I have time.
Lastly, and importantly, this attack is an offline attack. I wasn't able to find anything that compromises in-memory data. Granted, nothing other than 2FA will protect anyone (or DPAPI) against key loggers, but that's true for all OSs.
If local malware is the strength of the argument against DPAPI then I might as well go so far as to say that the most secure system is no system.
> Both of those seem easy enough to fix, which I imagine Microsoft has
> done (the exploit was discovered 3 years ago). I'm going to do a little
> more research when I have time.
Well, by your own confession, you've not read about a fix thus far, and Microsoft have been known to let poorer encryption APIs go unpatched for great lengths of time even when a problem is known (eg NTLM passwords aren't salted), so I wouldn't be the slightest bit surprised if this hasn't been patched either.
However, regardless of whether it has or hasn't, said patches only increase the CPU time it takes to crack the passwords, it doesn't make the passwords impossible to crack. And, as I'd already said, there's weaker links that can be exploited anyway.
> Lastly, and importantly, this attack is an offline attack.
All the attacks we're talking about here are offline attacks.
> Granted, nothing other than 2FA will protect anyone (or DPAPI) against key
> loggers, but that's true for all OSs.
Of course it's true for all OS's. I never once suggested otherwise. Honestly, I'm puzzled why you'd even bring that point up.
> If local malware is the strength of the argument against DPAPI then
> I might as well go so far as to say that the most secure system is no system.
Which is what myself and pretty much everyone else in this discussion have already been saying. At some point, there needs to be a balance between usability and security. I think NT (and Linux / BSD / Mach too for that matter) offer enough security to make in-memory password hacking awkward enough that it's a minor security risk while still leaving the host OS highly usable.
For the average user, social engineering will always remain the most exploited vector of attack, and for ultra sensitive servers, all we can do is lock them down as best as we can based on the latest fixes and proof-of-concepts. But a sufficiently determined attacker will usually find a way in if there's a sufficiently high enough incentive. Our job (or at least mine), is to make it sufficiently hard that attackers lose interesting trying. But if they've gained root access (in order to run any of the aforementioned attacks), then it's already game over - regardless of whether they manage to decrypt your RAM or not. Which is why I think the aforementioned API is akin to the emperors new clothes (ie all hype, no practical security)
Both of those seem easy enough to fix, which I imagine Microsoft has done (the exploit was discovered 3 years ago). I'm going to do a little more research when I have time.
Lastly, and importantly, this attack is an offline attack. I wasn't able to find anything that compromises in-memory data. Granted, nothing other than 2FA will protect anyone (or DPAPI) against key loggers, but that's true for all OSs.
If local malware is the strength of the argument against DPAPI then I might as well go so far as to say that the most secure system is no system.