« January 2007 | Main | March 2007 »

February 11, 2007

A classic example of approaching a security and privacy problem the wrong way

The Payment Card Industry (PCI) has embarked on a quest to improve the handling of sensitive user data, after a series of recent high profile breaches exposed the inadequacy of its security practices. The February 2007 issue of Information Security (p. 36) writes about a major initiative championed by Visa, MasterCard, Discover, and American Express that "is designed to ensure cardholder privacy."

Basically, this initiative mandates that cardholder data is to be protected (implied encrypted although not required) when transmitted across public networks. The standard goes at length to suggest and require that network infrastructure providers, retails (big and small) not store permanently the cardholder data, with the elephant in the room being the simple fact that knowledge of card number and card expiration date is often enough to place a transaction without actually possessing the card.

So, here is an industry that does not have any economic incentive to use the best available technologies to protect consumers (see Bruce Schneier's excellent points on this subject in the January 2007 issue of Information Security and my forthcoming letter that will appear in the March issue of the magazine) going at this problem from the wrong end. Credit card number, expiration date, and even the three-digit security code on the back, should not be the secrets that enable financial transaction to take place. Just think how much simpler the problem of protecting the consumer will become if we eliminate the reliance on compromisable secrets. Instead, PCI must adopt technologies that prove possession of the card by the proper cardholder at the time of the transaction. Smart card-based technologies are one example of such technology but the PCI in America resists deploying this and other similar solutions.  

February 02, 2007

ViewStateUserKey issue revisited

Deeper investigation shows that this security mechanism works in relatively simple scenarios: you have a page with a form on it, you click a button and the form is submitted back to the server. No problem.

Imagine, however, you have two pages: Account.aspx and login.aspx. Assume that both are derived from a base class Base.cs that sets

                  ViewStateUserKey = Session.SessionID;

in the OnInit() method. Let's further consider the case where in Account.aspx.cs you have

            protected void Page_Load(object sender, EventArgs e)

           {

                        if (User.Identity.IsAuthenticated == false)

                                   Server.Transfer("login.aspx");

           }

Login.aspx on the other hand has a login control whose target URL is Account.aspx.

The logic here ensures that anytime you want to access the account page and you are not authenticated, you are automatically forwarded to the login page, submit your credentials and then enter the account page.

Unfortunately, this breaks the ViewStateUserKey-based security mechanism. The ASP.NET 2.0 Framework fails to verify the integrity of login page at the server back-end.

Bottom line: if you utilize similar techniques in your Web site, you cannot use the ViewStateUserKey mechanism. Instead, you should rely on SSL and configure the ASP.NET RoleManager and Form authentication to require SSL.

February 01, 2007

The layered approach to internet security

One of the most fundamentally sound approaches to securing anything: your country, your house, your wallet, even your Web site, is the layered security approach. It simply means don't rely on a single defense, instead put several layers so that if one gets penetrated, there is the next one to protect you. Sounds good. Now, back to reality.

Try to implement such an approach using the latest ASP.NET 2.0 with the corresponding dev tools and you may run into a disappointing issue. Microsoft has introduced the ViewStateUserKey property to enable the IIS/ASP.NET 2.0 server to distinguish legitimate requests from fraudulent attempts. Put this mechanism under SSL and you have layered security for your Web site. Almost. It turns out this actually does not work on Web forms with reasonably complex controls: some JavaScript code or AJAX animation. In other words, precisely the kind of pages hackers prefer to hack. It turns out there is a bug in Visual Studio 2005 that messes this up and the server-side verification fails. Microsoft spoke last year of fixing this bug soon but it apparently still is not fixed in SP1 for Visual Web Developer Express.

So much for layered security. Rely on SSL for now and hope the software giant will come up with a fix soon.


Hosting by Yahoo!