Over the last couple days, most of my time has been devoted to the MaskedTextBox control, and one very annoying bug. The issues revolve around the way the control deals with currency. When provided with a mask such as ‘$999,999,999’ – you’d expect it to exercise some degree of intelligence. That expectation turned out to be quite wrong.
If you type the number ‘50’ in a box with that mask, you’ll end up with ‘$500,000,000’ – for a financial application such as the one I’m working on, that could lead to a major issue. The only way to get the proper value is to set the cursor two places from the right. So if the user doesn’t pay attention, it’ll be simple to enter a value that is completely wrong.
To add insult to injury, when the control receives focus, it has a habit of setting focus to the end of the mask, where the user can not type due to the length restriction. So the user has to move the cursor to the desired location before they can start to type, and if thy just start typing, the control happily ignores them.
After testing a couple possible solutions (this and this) it soon became clear that the MaskedTextBox is too limited in features to be useful for currency. That simple.
My solution to this was to drop the Masked control and create a new control inherited from TextBox that supports a few extra features such as:
- Numeric only input
- Minimum Value
- Maximum Value
- Format String support
With less than 30 lines of code, the basic control was in place. I wish I could include a proper answer for this issue to make the MaskedTextBox useful, but after losing two days, I can safely say it’s too limited to be of real value for even slightly complex uses.
Researchers are still working to understand the impact of the Juniper incident – the details of how the VPN traffic decryption backdoor are still not fully understood. That such devastating backdoors could make it in to such a security-critical product, and remain for years undetected has shocked many (and pushed many others deeper into their cynicism).
There are though, some questions that are far more important in the long run:
I really enjoy what I do, and though I work in a chaotic environment, I really do love my job. Being in the Software Development industry has some really nice perks, being a developer in today’s world really is a great thing. Development isn’t easy though, it is quite mentally demanding; clear focus is of paramount importance. Without absolute focus, progress will only be a dream. This fact is a key player as to what makes being in this industry so great.
Yesterday the news hit of a new vulnerability that threatens the security of all code; dubbed Trojan Source by the researchers from the University of Cambridge. From an initial analysis, it does seem to impact just about everything, and the status of fixes is very hit or miss at this point. But the real question is, does this even matter? Is this issue worth spending your time on? Let’s look closer.
Over the last year or so, I’ve become quite a fan of Air Disasters, a television show dedicated to analyzing plane crashes and similar incidents. As I watched the show, I started seeing many ways that the lessons and procedures around aircraft safety also apply to running a security team; this valuable and hard-won wisdom, often born out of tragedy, can be of significant impact if appropriately applied. In this article, I will explore Crew Resource Management and how it can be applied to Information Security to make teams run better.
Last Friday, Brandon Wilson and I gave a talk on BadUSB at DerbyCon – I wrote some about it yesterday. Yesterday, Wired published an article on the talk, kicking off several others – only the authors of the Wired and Threatpost articles contacted us for input.
There has been some questions raised as to the responsibility of releasing the code – so I want to take a few minutes to talk about what we released, why, and what the risks actually are.
