How-to safely keep a password field during postbacks and why it shouldn't be done

Download KeepPassword.zip - 6.0 KB

Disclaimer

The author does not accept responsibility for any effects, adverse or otherwise, that this code may have on you, your computer, your sanity, your dog, and anything else that you can think of. Use it at your own risk. (Deja Vu? I also love the Allegro disclaimer.)

Quick and dirty tour

So you don't like to read all articles you see on the web, or you don't have time for it? Then, just download the source files, and open the solution as a web project on your Visual Studio 2005 IDE and click play.

Background

You need only to have basic knowledge of ASP.Net and C# to use and benefit from the article.

Introduction

Stop where you are! Don't think about reading this article thinking about a magic solution for the world's problems. It is a very simple way of caring about more things than just the problem at hand. And also, minding about collateral effects of apparent feasible solutions.

Understanding the problem at hand

You have a page with a textbox on password mode that you need to persist the state during postbacks. .Net keeps erasing its content when you postback the page, and you want it no more! You just have to keep its data. Simple, right? Not really. I'll explain why it is so simple to explain and it is so trick to solve.

The illusion of solving a problem

During my early years as a .Net developer, few years ago, I stuck on this very problem, and by using my favorite friend consulting (google), I end up with a widely used solution (for newbies, of course).

It was something like this: You write the password field value back to itself on every page_load event. Wow! Lets see how it would like:

    protected void Page_Load(object sender, EventArgs e)
    {
        //does not work, .net will erase the content this way

        //txtPassword.Text = txtPassword.Text;

        //so adding an attribute on the client side would solve it. (do NOT use this!)

        txtPassword.Attributes.Add("value", txtPassword.Text);
    } 

That will solve the problem of loosing the password at a very high cost. Run the DoesNotSolveTheProblem.aspx page on the source solution. Type a user and password, click on the button and see that the password is indeed persisted. Now, click on view source on your browser. Look for the txtPassword HTML tag:

<input name="txtPassword" type="password" maxlength="128" id="txtPassword" value="123" />  

See anything that shouldn't be there? Your exposing the password, in plain text!

Solving the problem

There is a way for solving this problem very easily but It is a little tricky though.
First, you need to keep the password on the server side, so a way to do so is using a server-side variable...not! It would be erased every page load, so we go for ViewState.

It would like this:

    protected string TypedPassword
    {
        get 
        {
            if (ViewState["TypedPassword"] != null)
            {
                return Convert.ToString(ViewState["TypedPassword"]);
            }
            return null;
        }
        set 
        {
            ViewState["TypedPassword"] = value;
        }
    }

We also need to keep a fake data on the field (like a bunch of '*') to inform the user that there is data present in that field. We also need a way of detecting that the user typed a password, and that it is not the fake password we kept in the password field. Remember that '*' is a valid character for passwords!

Here comes the trick.

Passwords on modern windows system (post windows 98 versions), can have up to 128 characters, so we limit the HTML password field to 128 characters by using its maxlength property. We set the fake password mask to 129 '*' characters.

On every page load, we test if the password field is not blank and if it is different from the fake mask to detect if any change occurred.

        //detect if password was changed. if filled and not equal to mask, it is new 

        if (txtPassword.Text.Trim().Length > 0 && txtPassword.Text != PasswordMask)
        {
            TypedPassword = txtPassword.Text;
            txtPassword.Attributes.Add("value", PasswordMask);
        } 

Since the user can not type more than 128 characters, he can enter a password full of '*' characters and have a valid password. And how can we set 129 characters on a maxlength=128 field? Well, this validation occurs on the client side, so we are able to do whatever we want on server-side.

Now, the last part of the cryptic show. When the user clicks on the password field, we have to erase its content (it is 129 '*' chars, not the password itself, remember?) and let the user type the new password. To do so, we add a simple javascript code to do the trick.

This way, we do not compromise the security since the password is not in plain text on the page source. However, it is encoded (base64) in the viewstate hidden field, which can be used without encoding. My little piece of advice: don't.

See KeepPassword.aspx for the complete source.

Solving the right problem

This monster of keeping the password born because we created it by using bad design for our systems. If you put a little more effort on the design of an application, you could avoid this kind of tricky problems and came up with clean and robust approaches.

BetterDesign.aspx page have a complete example of a different way of looking to the same problem.

As you can see, there is no need to keep the password. When the user wants to change it, he just type it and that's all! Plus, asking for current password and for new password confirmation would improve security and avoid costly typos when setting new passwords.

You will see that this last solution does not use the typed password for storage purposes, but its hashcode (unique number generated from a string) instead. It is a common way of dealing with sensible data (as a password) and it is very simple too.

Catches

Besides the ViewState encoding situation I've mentioned before, there is another piece of information I must give you. Two strings can generate the same hashcode. Yes, I lied. But it is a so remote possibility that we usually forget about it for most applications. Caring about it and storing plain text passwords instead would be a blatant mistake.

Few comments on hashcode algorithms are also necessary. The GetHashCode() method used on this solution is good for learning purposes, but should not be used on real systems. Instead, you should use .NET provided (keyed or nonkeyed) hash algorithms like RIPEMD160Managed, SHA1CryptoServiceProvider or SHA1512Managed (example below, on jimmy_b comments). You can find lots of articles about the subject on code project, like Crypto.asp.

Also, I'm not using validators and any other .net feature here for the sake of simplicity. But it doesn't mean you shouldn't be using it. :)

Conclusion

That's all I have to offer you for now. Please feel free to ask for new functionality, report bugs or to tell me how boring is this stuff.

References

Some great resources on the web:

• Selecting Secure Passwords, Microsoft. Last access on 05/24/2007.

History

• 05-31-2007:
• Added few comments on hash algorithms, thanks to jimmy_b.
• 05-25-2007:
• Changed the "encryption" to "encoding", which is the correct term for viewstate. Thanks to William that pointed it out!
• 05-24-2007:
  • Original article.