Annoying IsReadOnly bug

While fixing the security flaw I encountered in WP7.5 FAS I bumped into another annoying issue.

I fixed the FAS issue by hiding the password from view until you drag your finger over it.  When the TextBox has focus the password is displayed as soon as you move away it reverts to showing *********.  Neat and clean!

However the mouse over event can also turn into a Tap event and this causes the WP7 UI to show the on screen keyboard and start editing which is just a UI mess, as all the users is really trying to do is view the information and not change it.  Worse still – quite often the password is shown as ********* for editing!

In order to keep the UI clean I simply set the TextBox to have IsReadOnly=”True” and then the keyboard does not appear.  All seems good – the password is shown when the finger is dragged over it and the UI only drops into edit mode when the user wants to make a change by pressing the Edit button on the toolbar. 

But then during testing my App would sometimes crash when resuming from FAS suspension.  It would show ‘Resuming…’ on the screen and never actually resume…

It took quite a while to establish that it was the IsReadOnly=”True” setting that was causing the problem.

I suspected I could fix it by removing the focus when the App was deactivating but didn’t know how so was pleasantly surprised when the excellent Richard Woo pointed me to the solution when I posted the bug on the App Hub Developer Forum.

I dropped the code into place and the issue is resolved.

public NewItem()
{
    InitializeComponent();
    PhoneApplicationService.Current.Deactivated += new EventHandler<DeactivatedEventArgs>(Current_Deactivated);
}

/// <summary>
/// Handler to remove focus from a TextBox that is read only.  This cures
/// the exception that occurs when resuming.
/// </summary>
void Current_Deactivated(object sender, DeactivatedEventArgs e)
{
    var focusedElement = FocusManager.GetFocusedElement();
    if (focusedElement is TextBox)
    {
        if ((focusedElement as TextBox).IsReadOnly == true)
        {
            this.Focus();
        }
    }
}   

Advertisement

Security Flaw in WP7.5

I came across a security flaw in what is a neat feature in WP7.5 – I am talking about Fast Application Switching (FAS).

FAS is quite simple – press the Start button while running an App and it switches to the background.  Press and hold the back button and all the Apps in the background are displayed as a scrollable list. Touch an App and its brought back to the front.  All quite neat and useful.

However it is flawed because when the App is switched a screen shot of whatever was on the screen at the time is displayed as the background image like this:

This screenshot is not that clear but ThisIsMyPassword is clearly visible!

Microsoft are aware that this is an issue and have argued that it is the users responsibility to use the phone appropriately and  keep data secure but this is a cop out in my opinion.  FAS is pretty transparent to the user – I wasn’t even aware of it when I upgraded my phone from WP7.

As an App author I have a responsibility to my users for keeping the data they have entrusted to my App as secure as possible.  I have gone to considerable effort in Master Key to ensure that the password data is secure under as many different user scenarios as possible.

In the original WP7 OS when the Start button was pressed the foreground App is closed using a process called tomb-stoning.  The App is given a chance to saved its current state prior to being shut down.  When the back button is pressed the App is restored back to the screen that was in operation.

The state management process is handled with OnNavigated events and it is the App developers responsibility to save/load the state in the event handlers.  It’s a bit of a hassle to handle tomb-stoning because it is a snapshot of where the user is at the time and cannot really show how the user got into that state automatically.  It falls on the App developer to provide additional data so that on resumption the App comes back to a working state.

In Master Key version 2.0 written with WP7 in mind when the App is resumed from tomb-stoning it returns to the login screen forcing the user to re-enter the master key password and reload the encrypted data from isolated storage.

When FAS is invoked the same tomb-stoning process is used but as a developer I don’t get a chance to control the screenshot that is taken as there is no specific API and no chance to influence what it going to be taken as screen grab occurs before the OnNavigated event is invoked.

The only solution is to ensure that the screen is maintained in a safe state so that the screen shot, whenever it occurs, will also be safe.  I implemented a solution by catching the MouseEnter/MouseLeave events and only displaying the password as the user swipes over the password box.  As soon as the mouse leaves the password box it is hidden again.

This code example which is hooked into the password box event handlers shows the password as asterisks and then displays the actual password as soon as the MouseEnter is triggered.  I had to catch the Tap event as well, as it catches and prevents the MouseLeave event from firing which would otherwise leave the password on display.

private string Password="MyCurrentPassword";
private string PasswordHidden = "".PadLeft(Password.Length, '*');
private void OnMouseEnter(object sender, System.Windows.Input.MouseEventArgs e)
{
    textBoxPassword.Text = Password;
}

private void OnMouseLeave(object sender, System.Windows.Input.MouseEventArgs e)
{
    textBoxPassword.Text = PasswordHidden;
}

void OnTap(object sender, System.Windows.Input.GestureEventArgs e)
{
    textBoxPassword.Text = PasswordHidden;
}

The result looks like this:

Ideally Microsoft will provide an API that would let the developer substitute another screenshot in place of the default – the splash screen for example.  Until then its up to us to jump over a couple of hurdles to keep the data secure from prying eyes!