I'm not complaining about the fact that I can't see what I'm typing. I understand and laud that feature, because I don't want someone looking over my shoulder at the password I'm typing, and this even applies when I'm at home. I love my children, but I certainly don't want them knowing the password to my bank account!

No, what I'm bothered by is how a typical password text box behaves on a form that may incur multiple post-backs before it's finally submitted. If you use the built in ASP.NET TextBox control, it purposely does not repopulate the password text, which means if you press a button on the form that performs a post-back, or if you have a multi-page form that posts back on every step, that password disappears, and the user typically has to re-enter it. You could solve this with liberal use of ASP.NET Ajax UpdatePanels, but that adds its own complexities. I wanted a simpler solution.

So I did a little research to see what others had discovered about this problem, and I ended up deriving my own custom control from TextBox to make a much more user-friendly (and developer-friendly) TextBox control. I called it PasswordTextBox, and it acts just like a TextBox in password mode, but it retains the password while still giving the user the same level of protection the standard TextBox supplies.

My PasswordTextBox operates very simply: it stores the password in control state, and renders a series of fixed characters (with the same length as the actual password) into the text box so that it "looks" like the user's password has been rendered. Since control state is part of view state, and since view state is stored in a hidden field on the form, I encrypt the password before putting it into control state.

The result is quite nice - the user can post your form back as many times as she needs to, perhaps moving back and forth across wizard steps or tabs, and when she finally presses the "Finish" button (or whatever you call the last step of your input form), your code will be able to read the password by simply accessing the Text property on the PasswordTextBox. The user will believe that her password is sitting there on the form while she's working, as the same number of obfuscated characters will show up in the field as she typed in originally (what she doesn't know is that those characters aren't her real password anymore, but what she doesn't know won't hurt her!)

Note that to keep this simple, I used DPAPI to encrypt the password, which suited my purposes. But if you have a web farm, that won't work well at all if you don't know which machine the user's going to post back to, so you'll want to replace that with something more robust. I could see looking up the <machineKey> for entropy, as that tends to be sync'd already across the farm, but I've not yet spent the cycles to go down that road, since unfortunately all of the code for generating keys based on that config section are off limits in ASP.NET (most of the useful stuff is marked internal). I don't think it'd be that hard to do though.

Anyway, without further ado, here's the code, which you'll see is quite simple. I'd love feedback, especially if you see any glaring problems with the idea or the implementation!

public class PasswordTextBox : TextBox
{
    // unlikely that a string of these would be used for a password
    const char PasswordPlaceholderChar = '}';

    string password; // stored encrypted in control state

    protected override void OnInit(EventArgs e)
    {
        base.OnInit(e);
        Page.RegisterRequiresControlState(this);
    }

    protected override object SaveControlState()
    {
        byte[] encryptedPassword = ProtectPassword(password);

        object baseControlState = base.SaveControlState();
        if (null == baseControlState)
            return encryptedPassword;
        else return new Pair(baseControlState, encryptedPassword);
    }

    protected override void LoadControlState(object savedState)
    {
        byte[] encryptedPassword;

        Pair pair = savedState as Pair;
        if (null != pair)
        {
            base.LoadControlState(pair.First);
            encryptedPassword = pair.Second as byte[];
        }
        else encryptedPassword = savedState as byte[];

        password = UnprotectPassword(encryptedPassword);
    }

    /// <summary>
    /// This control always uses TextMode=Password
    /// </summary>
    public override TextBoxMode TextMode
    {
        get
        {
            return TextBoxMode.Password;
        }
        set { }
    }

    /// <summary>
    /// TextBox doesn't render value attribute for TextMode=Password
    /// So we add code that renders a placeholder text instead
    /// </summary>
    /// <param name="writer"></param>
    protected override void AddAttributesToRender(HtmlTextWriter writer)
    {
        base.AddAttributesToRender(writer);

        string text = Text;
        if (text.Length > 0)
            writer.AddAttribute(HtmlTextWriterAttribute.Value,
                GetPlaceholderPassword(text));
    }

    /// <summary>
    /// TextBox doesn't save the "Text" viewstate in
    /// TextMode=Password and we don't want our behavior to break
    /// if ViewState is turned off so we store the password in
    /// Control State, encrypted with MachineKey
    /// </summary>
    public override string Text
    {
        get
        {
            return password ?? string.Empty;
        }
        set
        {
            // this prevents us overwriting the actual
            // password with a placeholder
            if (!string.IsNullOrEmpty(password) &&
                value.Equals(GetPlaceholderPassword(password)))
                return;

            password = value;
        }
    }

    private string GetPlaceholderPassword(string realPassword)
    {
        int length = 12;
        if (!string.IsNullOrEmpty(realPassword))
            length = realPassword.Length;

        StringBuilder sb = new StringBuilder();
        sb.Append(PasswordPlaceholderChar, length);

        return sb.ToString();
    }

    public byte[] ProtectPassword(string password)
    {
        if (string.IsNullOrEmpty(password))
            return null;
        byte[] cleartext = Encoding.UTF8.GetBytes(password);
        return ProtectedData.Protect(cleartext, null,
            DataProtectionScope.LocalMachine);
    }

    public string UnprotectPassword(byte[] ciphertext)
    {
        if (null == ciphertext)
            return null;
        byte[] cleartext = ProtectedData.Unprotect(ciphertext, null,
            DataProtectionScope.LocalMachine);
        return Encoding.UTF8.GetString(cleartext);
    }
}

Blogger: Ramon Krikken

The web browser is one of those peculiar pieces of software, having to accept input from arbitrary sources and then parse and render the data that is sent to it. Part of this it does by itself, and other parts are taken care of by handlers and plug-ins. In doing so, it displays hypertext, images, videos, and even runs active content like Flash, JavaScript, and ActiveX.

But however much we love the browser, we’ve also come to hate the myriad of vulnerabilities that affect it. Everything from cross-site scripting to remote code execution via maliciously formed animated cursor files and Flash content can make browsing a hazardous activity. The browser is sick, and that’s not desirable for a platform we use for important business and personal transactions.

Worsening the browser’s diagnosis is the recent paper from Mark Dowd and Alexander Sotirov, sub-titled “Setting back browser security by 10 years,” which discusses how to bypass Microsoft Vista’s memory protection capabilities with some added effort for the exploit designers. It’s not that all of the techniques are necessarily new, but the browser appears to be particularly vulnerable to easy exploitation.

Surprising? Not exactly, when we take into account that the browser is suffering from the same disease as the general purpose operating system: bloat and compatibility. We expect the browser to do ever more, but everything we used it for before still needs to work as if it were yesterday. It feels a bit like people insisting on using a cardboard box as a safe, and wondering why their money keeps getting stolen.

It’s not like we haven’t been working on the browser’s cure, though. There have been some improvements in the browsers themselves, the operating systems have also implemented compensating controls, but most of all, there has been an enormous push for securing the web applications that deliver the data in the first place. Unfortunately, the latter two won’t help secure the browser in the long run.

The first issue is that not all content will come from ‘nice’ servers, the second that the server can only make an educated guess on how a browser will parse and render a given set of data, and the third that operating system controls have their own limitations, whether by design or implementation (for example needing to re-compile existing code to enable certain protections.) The browser, in the end, has to be mostly responsible for keeping itself safe; the operating system must assist it in doing so.

So we’re in a pickle. The browser is sick (and the operating system is too), but it’s hard to cure it without a redesign that will undoubtedly impact compatibility, the ever-so-desired multi-functionality, or its ease of use. We can layer defenses by using web filtering in the enterprise environment, but in the end – for the consumer market in particular – we need to fix the browser itself. I can think of a few things I think might help:

• Some kind of site security policy  to restrict where the browser loads auxiliary content from, and which data it can ‘trust’, when loading a web page (I’d prefer mandatory enforcement, and adding an HTML tag to be able to indicate blocks of untrustworthy data.)
• Restricted compartments for plug-ins to run in, ensuring that their bugs cannot easily affect the whole browser.
• Better software development practices for the plug-ins and content parsers themselves, so that they’re less vulnerable, and compiled with the latest protection measures to begin with.

All of this means more work, and some of it means a lot of unhappy reactions when things stop working. Even then we will of course still have to deal with additional vulnerabilities, such as those that may be present in hardware, but we will at least have taken prudent steps to ‘find a cure.’

Blogger: Ramon Krikken

The web browser is one of those peculiar pieces of software, having to accept input from arbitrary sources and then parse and render the data that is sent to it. Part of this it does by itself, and other parts are taken care of by handlers and plug-ins. In doing so, it displays hypertext, images, videos, and even runs active content like Flash, JavaScript, and ActiveX.

But however much we love the browser, we???ve also come to hate the myriad of vulnerabilities that affect it. Everything from cross-site scripting to remote code execution via maliciously formed animated cursor files and Flash content can make browsing a hazardous activity. The browser is sick, and that???s not desirable for a platform we use for important business and personal transactions.

Worsening the browser???s diagnosis is the recent paper from Mark Dowd and Alexander Sotirov, sub-titled ???Setting back browser security by 10 years,??? which discusses how to bypass Microsoft Vista???s memory protection capabilities with some added effort for the exploit designers. It???s not that all of the techniques are necessarily new, but the browser appears to be particularly vulnerable to easy exploitation.

Surprising? Not exactly, when we take into account that the browser is suffering from the same disease as the general purpose operating system: bloat and compatibility. We expect the browser to do ever more, but everything we used it for before still needs to work as if it were yesterday. It feels a bit like people insisting on using a cardboard box as a safe, and wondering why their money keeps getting stolen.

It???s not like we haven???t been working on the browser???s cure, though. There have been some improvements in the browsers themselves, the operating systems have also implemented compensating controls, but most of all, there has been an enormous push for securing the web applications that deliver the data in the first place. Unfortunately, the latter two won???t help secure the browser in the long run.

The first issue is that not all content will come from ???nice??? servers, the second that the server can only make an educated guess on how a browser will parse and render a given set of data, and the third that operating system controls have their own limitations, whether by design or implementation (for example needing to re-compile existing code to enable certain protections.) The browser, in the end, has to be mostly responsible for keeping itself safe; the operating system must assist it in doing so.

So we???re in a pickle. The browser is sick (and the operating system is too), but it???s hard to cure it without a redesign that will undoubtedly impact compatibility, the ever-so-desired multi-functionality, or its ease of use. We can layer defenses by using web filtering in the enterprise environment, but in the end ??? for the consumer market in particular ??? we need to fix the browser itself. I can think of a few things I think might help:

• Some kind of site security policy  to restrict where the browser loads auxiliary content from, and which data it can ???trust???, when loading a web page (I???d prefer mandatory enforcement, and adding an HTML tag to be able to indicate blocks of untrustworthy data.)
• Restricted compartments for plug-ins to run in, ensuring that their bugs cannot easily affect the whole browser.
• Better software development practices for the plug-ins and content parsers themselves, so that they???re less vulnerable, and compiled with the latest protection measures to begin with.

All of this means more work, and some of it means a lot of unhappy reactions when things stop working. Even then we will of course still have to deal with additional vulnerabilities, such as those that may be present in hardware, but we will at least have taken prudent steps to ???find a cure.???

Scrawlr quickly came under fire on the Web Security mailing list for having some pretty major limitations. Billy Hoffman et al have been quick to point out that the tool was designed to address a very specific subset of SQL Injection vulnerability — the type affected by the mass attacks — and is not designed to be a general purpose replacement for existing SQL Injection scanners. Let’s look at the limitations, as outlined on the HP page, one by one.

Limitation: Will only crawl up to 1500 pages

Depends on what they mean by 1500 pages. For example, if I have these links on my front page, is that one URL or three?

• http://www.veracode.com/blog/?p=111&foo=1
• http://www.veracode.com/blog/?p=111&foo=2
• http://www.veracode.com/blog/?p=111&foo=3

Or, does it mean that it will really only crawl 1500 pages total, so if I have the same link 1500 times on the front page, it won’t go any further? Either way, for most smaller websites this is probably fine. If you need more than 1500 you could give it different starting URLs in an attempt to improve coverage. It would be nice to have a clearer definition of what it means to “crawl up to 1500 pages” though.

Limitation: Does not support sites requiring authentication

Well, this will render it useless for the majority of enterprise apps. But there are still a lot of sites out there that don’t require authentication, including some of the ones that got hit during the mass attacks, such as the United Nations, UK government, etc.

Limitation: Does not perform Blind SQL injection

They have taken a lot of flack for this but Billy describes it as a conscious choice:

An early version of the tool checked for blind SQL injection, but the final verison of Scrawlr did not. … The biggest feedback we got from early testing was developers wanted to “see” the vulnerability. Differential analysis is kind of difficult to visualize in a way that is helpful for the average dev, and pulling the table names through blind was too much of a performance issue.

I can sort of understand this rationale. Blind SQL Injection testing is much more susceptible to false positives. As users of any commercial web scanner or source code analyzer will attest, the more time you spend chasing down FPs, the less likely you are to put any faith in future results. It’d be nice if there was a way to toggle Blind SQL Injection testing on and off, though (could be off by default so nobody gets confused).

Limitation: Cannot retrieve database contents

Who cares? Find and fix the vulnerability. Pulling down the entire database “because you can” is a total ego move.

Limitation: Does not support JavaScript or flash parsing

Nobody does this very well anyway, particularly the JavaScript part. Writing a great crawler is probably the hardest part of writing an automated web scanner and it’s one of the biggest differentiators from one product to the next. You’re not going to get that for free.

Limitation: Will not test forms for SQL Injection (POST Parameters)

This is probably the toughest one to swallow. It’s not that difficult to parse out forms from HTML, and form POSTs can represent a major chunk of the attack surface. Granted, the Chinese tool associated with the mass attacks did operate solely on GET requests (i.e. parameters in the query string) so HP can defend this again by saying the tool is really aimed at the sites being targeted by the mass attacks. I think it’s a little short-sighted though; chances are that the mass attacks will evolve and it’s better to be proactive about it than reactive.

Conclusion

It’s tough to bash someone for releasing a free tool. I personally think HP should add an option for enabling Blind SQL Injection testing, and that they should consider supporting POSTs as well as GETs. You’re basically getting a (massively) stripped-down WebInspect for free, so take it for what it is. No single tool is a panacea.

The jury is still out on how effective Scrawlr is against the things it does claim support for. Keep watching the Web Security list; the reviews are filtering in.

Note that the iPhone 2G and 3G aren't more powerful than other, similar devices. Symbian platform devices from Nokia and others are in notably short supply in the US, but come in great quantities and varieties elsewhere, and have some pretty impressive computational power; Nokia owns nearly 50 percent of the worldwide smartphone market. Likewise, you can run desktop-to-mobile programs under Windows Mobile that let you have real computer applications repackaged for better use in the smaller form.

But that's not what the iPhone is about. It's a non-compromise device, even when a little compromise might help. The lack of a touch-typist keyboard hinders data entry, but it doesn't restrict any other purpose of the device. The inclusion of those keyboards is a huge compromise for all its competitors, even though it allows those competitors to act more like little computers.

And that's where it's odd for me. The iPhone is much more like a full-blown computer than any smartphone I've used. It might be the superior browser, and the fact that a single company and design vision has ensured the maximum CPU is available for each current task, and that the interface and actions are nearly always consistent across every piece of software. Contrast that with many smartphones that don't just have ugly interfaces, crippled Web browsers, and varying input methods, but also require you to learn a different approach to using nearly every different piece of software on the phone.

Apple isn't about to kill its competitors, but they are providing an odd amount of support for killing a laptop.

On a slightly tangential front, Apple CEO Steve Jobs claim that their phone's 3G speed was nearly that of Wi-Fi requires some explanation. Jobs needed a footnote: "compared to typical Wi-Fi hotspots that have about 1.5 Mbps of downstream backhaul." The iPhone is clearly processor limited for how fast it can render Web pages and handle network processing. If you stick an iPhone on a 10 Mbps-backed network via Wi-Fi, the browsing experience isn't very different than on a 1.5 Mbps-backed Wi-Fi hotspot, in my experience with the current phone.

So clearly, there's more optimization to be done and more hardware upgrades to come in order to have a mobile device that can live up to whatever network it generally works on. For the iPhone 3G, Wi-Fi is an alternative, but it's clearly not intended as a superior alternative.