Isolated storage is not FIPS compliant

I talked earlier about using Isolated storage in order to save a clients information in an encrypted format locally - things like passwords used to connect to a server, etc. The application that i've been brought to work on would previously save the password information as an encrypted string, in an unencrypted file. The unencrypted file was bad enough, but even if the string is encrypted, this offers no protection. Since the file isn't tied locally to the machine in any way, anyone could just copy the file to a different machine, and without even knowing what the password is, be able to access the server with no issues.

So enter Isolated storage, which I thought would have fixed this issue. The main problem, which i just found out yesterday, is that it isn't FIPS compliant, which is a big problem if your application is going to be run on government computers. I was testing our application on a machine with the group policy setting set to require FIPS compliance, and it came up with an error. Apparently the encryption that Isolated Storage uses is the Sha1Managed class. There isn't a whole lot of documentation that I could find on which classes are FIPS compliant, although I did find this helpful blog explaining an easy way to find out.

FIPS compliance has come up as an issue for me in the past. I've been disappointed that RijndaelManaged, which is the .Net version of AES, isn't FIPS compliant. This leaves the best encryption in .Net classes that I can use as TripleDES.

A good solution to replace Isolated Storage is to create your own encrypted file, encrypted using TripleDES. Using ManagementClass("Win32_Bios"), and getting it's SerialNumber value to use as the salt should work fairly well for most needs.