#1,134 – Localization XV – Localizing Other Content

August 12, 2014 1 Comment

You’ll sometimes have content in an application that needs to be localized but is not already present in a XAML file.  Below, a MessageBox uses a hard-coded string.

        private void Button_Click(object sender, RoutedEventArgs e)
        {
            string message = "Apples are crunchy, portable and taste great!";
            MessageBox.Show(message, "Apples");
        }

One approach to this is to move the string into a XAML file as a resource and then localize the string when localizing all of the other content in the XAML file.

We start by including an XML namespace that defines an alias for the System namespace.

        xmlns:sys="clr-namespace:System;assembly=mscorlib"

We can now add the string as a resource (e.g. within a <Window> element).

    <Window.Resources>
        <sys:String x:Uid="sys:String_1" x:Key="AppleMessage">Apples are crunchy, portable and taste great!</sys:String>
    </Window.Resources>

At run-time, we can load the resource rather than a hard-coded string.

            string message = (string)this.Resources["AppleMessage"];
            MessageBox.Show(message, "Apples");
Advertisement

Filed under Localization Tagged with , ,

#953 – Use a SecureString Object to Store Confidential Text Data

November 19, 2013 6 Comments

There can be security issues with storing confidential data in the System.String type, given that the string exists in plaintext in memory and you can’t explicitly control the amount of time during the string is present in memory.

The SecureString class provides a more secure way of storing confidential string data in memory.  SecureString is more secure than the String data type because:

  • It stores the string data in memory in an encrypted form
  • The encrypted data is stored in unmanaged memory and therefore not visible to the garbage collector
  • It allows appending, inserting or removing characters, but re-encrypts the data after modifying it
  • It is mutable, avoiding the need to create extra copies when modifying the secure string
  • It zeros out the contents of the string when the SecureString object is disposed (or finalized)

Filed under Security Tagged with , , ,

#952 – Security Issues with Managed Strings

November 18, 2013 5 Comments

Confidential data stored in strings is vulnerable to attack during the time period that the string is stored in memory.

String data stored in managed strings in .NET is less secure than data stored in unmanaged strings.  Plaintext (non-encrypted) string data in managed strings has a longer period of time during which it is stored in memory.

Because managed strings exist on the garbage collected heap, you can’t explicitly destroy them.  The data will remain in memory until after the garbage collector has released the memory and it has been overwritten by some other object.

Since strings are immutable, you can’t overwrite the string data in a managed string object.  Writing new data results in a new instance being created.  The Garbage Collector may also create extra copies when it compacts memory.  The string data is less secure, due to the likelihood of there being multiple copies and its longer lifetime.

Filed under Security Tagged with , , ,

#951 – Security Issues when Storing Confidential Data in Strings

November 15, 2013 1 Comment

Applications often have periods of time during which they need to work with confidential string data, e.g. credit card numbers or passwords.  Whenever you store this confidential string data within memory, the data is vulnerable to being read by any other process on your machine that can read your application’s memory.

Since memory can be swapped out to disk, confidential data stored in memory can also end up being stored on disk, making the data vulnerable for a longer period of time.

No matter what language your application is written in, these vulnerabilities exist whenever you store confidential data within memory as a plaintext (non-encrypted) string.

When writing code that deals with confidential data, you’ll eventually need to work with that data in memory.  To maximize security, you want to reduce the amount of time during which the plaintext version of data is stored in memory.

Filed under Security Tagged with , ,