I am using Isolated Storage with the following flags:

IsolatedStorageScope.User |IsolatedStorageScope.Domain | IsolatedStorageScope.Assembly

How much security will this provide? Are there any vulnerabilities or gotcha's?

Note: I am not solely relying on isolated storage. My application encrypts the data, but without recording the password. Of course, it will be vulnerable to key loggers and programs that read the decrypted data from RAM, but I don't think its possible to protect against these.

2 Answers 2


You should look at the .net SecureString class if you are worried about storing data in RAM: http://msdn.microsoft.com/en-us/library/system.security.securestring.aspx

Here is some important info about isolated storage: http://msdn.microsoft.com/en-us/library/3ak841sy.aspx

Although isolated storage is well suited to the scenarios described previously, there are a few cases in which you should not use isolated storage:

  • Do not use isolated storage to store high-value secrets, such as unencrypted keys or passwords, because isolated storage is not protected from highly trusted code, from unmanaged code, or from trusted users of the computer.

Without knowing more about your application you might want to look at using DPAPI via the ProtectedMemory class.

This way you either secure the data based on the current user, or based on the current machine. Obviously if you can restrict it to the current user the data will be more safe.

So, Isolated storage provides a safe place to store data (you won't have to worry about overwriting other applications data, but it is not secure). ProtectedData will ensure that the data is secure where it is stored.

Hope that helps.


  • do you mean this link? if so, i'll edit it into your post and have one of the 2k+ rep people approve it: msdn.microsoft.com/en-us/library/… Commented Jul 26, 2011 at 12:55
  • Didn't DPAPI have a vulnerability discovered?
    – Casebash
    Commented Jul 26, 2011 at 22:16

Of course, it will be vulnerable to key loggers and programs that read the decrypted data from RAM, but I don't think its possible to protect against these.

Unless the content you want to protect is highly valuable, I'd say you're probably right to dismiss these. Reading the decrypted data from RAM would be non-trivial and probably suggests a targeted attack if it is after your application's RAM specifically.

Isolated Storage appears to be a .net abstraction on top of Windows rather than an extension to the Windows API itself. This MSDN article reveals that the locations are, essentially, just the usual Application Data paths. The impact of the user, domain and assembly flags is summarised in this article.

I'm not a .net developer per se, so I decided the best way to test what happened would be to use the demo from codeproject, have a look at the directories and watch it with procmon.

So, first up, what sort of security attributes does C:\Users\username\AppData\Local\IsolatedStorage have?

Windows security settings dialog

It doesn't, in conlusion, appear to have any specific access rights beyond what a usual user might expect to use.

Inside the Isolated Storage folder

Indeed, as you see above, I can waltz on in. Finally, having a go with procmon:

ProcMon API intercepts

You might need to zoom that one, but as an interpretation, that's just a standard set of Windows API calls and a bit of locking access to the file. Because it might be of interest, what I was looking for was a call to SetNamedSecurityInfo() which shows up as IRP_MJ_SET_SECURITY.

In short, I think IsolatedStorage is Isolated as a .net abstraction, but .net runs currently on top of Win32, from which it provides no defence I could think of. So, it's as secure as writing files to My Documents or any other App Settings location you care to pick from the perspective of a Win32 App. Which is exactly what Ross has said - no defence from unmanaged code. I just like pictures.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .