Best practice for saving sensitive data in Windows 8

12k views Asked by At

What's the best way of saving sensitive data to a local file in Windows 8? I'm developing a C# application that needs to store oAuth tokens/passwords. I've heard it was common in .NET to encrypt/decrypt data, but I don't have any experience with those mechanics. Is encryption still recommended/neccesary given that Windows 8 apps have their own personal/protected storage area similar to Windows Phone?

Also, doesn't encrypting/decrypting each time when you request the data causes a performance issue? (would it be better to write a custom/lite algorithm?)

3

There are 3 answers

13
Robert Levy On BEST ANSWER

UPDATE: Please be aware that while modern/metro apps are restricted from poking at each other's stuff, desktop applications will have unrestricted access to all data stored through these APIs. See http://www.hanselman.com/blog/SavingAndRetrievingBrowserAndOtherPasswords.aspx which includes code demonstrating this.


Win8 has a new API called PasswordVault that's designed for taking care of all these hard problems for you. Really easy to use, secure, and can be configured by users to roam between their machines so they only have to enter credentials once. I've successfully used this for OAuth tokens

Retrieving credentials (note the stupid exception that WinRT raises... they really should just return null):

const string VAULT_RESOURCE = "[My App] Credentials";
string UserName { get; set; };
string Password { get; set; };
var vault = new PasswordVault();

try
{
   var creds = vault.FindAllByResource(VAULT_RESOURCE).FirstOrDefault();
   if (creds != null)
   {
      UserName = creds.UserName;
      Password = vault.Retrieve(VAULT_RESOURCE, UserName).Password;
   }
}
catch(COMException) 
{
   // this exception likely means that no credentials have been stored
}

Storing credentials:

vault.Add(new PasswordCredential(VAULT_RESOURCE, UserName, Password));

Removing credentials (when the user clicks the logout button in your app):

vault.Remove(_vault.Retrieve(VAULT_RESOURCE, UserName));
4
Dante1986 On

you could encrypt like this:

    public static string EncodePassword(string password)
    {
        byte[] bytes = Encoding.Unicode.GetBytes(password);
        byte[] inArray = HashAlgorithm.Create("SHA1").ComputeHash(bytes);
        return Convert.ToBase64String(inArray);
    }

And when checking the user input, you also trow it into this method and check for it to match.

In case of data that you put in an xml (for example) that you want to encrypt/decrypt you can use RijndaelManaged.

-Edit1-

An example: if you have a small login screen that pops up (ShowDialog) you can is it like this snip-it:

private void settings_Click(object sender, RoutedEventArgs e)
{
    Login log = new Login();    //login window
    log.ShowDialog();           //show the login window
    string un = log.userName.Text;  //the user input from the username field
    string pw = log.passWord.Password; //the userinput from the password input
    if (EncodePassword(un) == Properties.Settings.Default.adminUsername && EncodePassword(pw) == Properties.Settings.Default.adminPassword) //in my case, i stored it in the app settings, but this could also be somewhere else.
    {
        //login was correct
        //do something
    }
    else
    {
        //login was not correct
    }
}
1
HansPolders On

It depends on what you need, if you realy need to store the passwords you should use a 2-way encryption algorithm like 3DES/RC2/Rijndael etc.

However, if all you need to be able to do is verify if a password is correct it is recommended to use a oneway function to store a hash.

When dealing with sensitive data I realy recommend the encrypt/hash it, even if you use windows 8. Encryption does mean extra overhead but in most cases you will not notice the speed difference.

Would it be better to write your own custom/lite algorithm? As a security guy I advise against it. People spend years testing, improving and trying to find holes in existing algoritms. The ones that survived are therefore quite good.