Security on the Client Side

Common--and good--advice is to not trust the client. If an organization has no control over the client, as is the case in web-based client-server applications, the client is not trustworthy. The Milwaukee Journal-Sentinel's Packer Insider is a very good low-stakes example of a site that has gotten this wrong. The Packer Insider is intended to be a subscription-only service, but I was reading it for a while, perhaps a long while, before I realized I was reading for-pay content.

If I visit http://www.jsonline.com/sports/packers/ in Firefox I get full access. If I visit it with Opera or Chrome, and click one of the Insider links, I get a login screen. What's the difference?

The difference is NoScript, an indispensable Firefox tool. NoScript is not intended to circumvent security, but rather to enhance client-side security. The idea is that if I let any given web site execute any script it wants on my machine, my personal data and the integrity of my machine are at risk. NoScript also helps me limit more obnoxious advertising by selectively shutting off Flash, JavaScript, Java, etc. NoScript uses a default-deny model, meaning that sites are not allowed to run client-side scripts unless I assent. NoScript is not for everyone because it does cause problems with some sites and it does require some effort on the part of the user, but it does provide a much safer browsing environment.

So, if I disable scripting, I get a much cleaner, more pleasurable view of the Journal Sentinel's Packer pages. As a side effect, I also get access to the Packer Insider materials. This is due entirely to poor security architecture at the Journal Sentinel's site, and, IMHO, strong evidence that the design was not done by an experienced professional. OTOH, there may have been other constraints making this desirable, and they may not actually care. If I were to lose access to these pages, I wouldn't really care because the Green Bay Press Gazette has comparable content that's openly-available.

As an aside, there are those that think it is bad to disable advertisements that support web sites. I have sympathy for this view, but I don't want their scripts running on my machine, eating cycles, providing animations which make it difficult to concentrate on the actual content, and, in extreme cases, making noise or damaging my system. I will aggressively block Flash, animated GIFs, etc., that damage the user experience.

This shows a general advantage of server-side over client-side scripting. Providers have a better idea of what their pages look like on the client side if they use server-side scripting--which is controlled by the provider--rather than client-side scripting, which is controlled by the end user, the browser, malware, etc.

Summary: security must be on the server side.

LinkedIn Not Worth it Anymore

LinkedIn has been of some value to me in terms of getting back in touch with former coworkers. But they've changed their authentication so that, instead of a login session lasting for the life of a browser process, it times out every day. So now I have to log in every single time I want to visit their site. It's ok with me that Amazon wants my password every time I place an order, but LinkedIn doesn't have my credit card numbers and so forth.

Am I going to delete my LinkedIn account? Not in the immediate future.

Am I going to bother to look at LinkedIn based on the "LinkedIn Network Updates" they send out every week or so? No--it's no longer worth my time.

Am I going to keep my profile up-to-date? Probably not.

Will I periodically visit LinkedIn when I think of a former colleague and wonder where he or she is? No, it's not worth the time.

Identity & Authentication Must be Kept Separate

In a recent newsletter, Bruce Schneier referred to an article at Microsoft TechNet by Steve Riley, a Senior Security Strategist. The article is pretty good overall, and certainly worth reading. It's also short, so I won't bother to summarize it here. Instead, I'll just make a few comments:

• The point that basic computer science principles cannot be glossed over is quite welcome.
• The statement that the system knows the password is usually, one would hope, incorrect. If passwords are kept anywhere in the system, that file becomes a high-value target. Passwords should have salt shaken on them and then be hashed. The salted hash can be safely stored, and used to verify the user's password.
• Other examples of authentication with no corresponding identity include boot passwords and disk encryption pass phrases.
• I'm happy to see anyone make the point, which Riley makes here, that biometrics are best viewed as identity, not as authentication. Biometrics are (typically) public and irrevocable, which make them bad choices for authentication.

Another place where identity and authentication are muddled is with RFID in passports, border crossing cards, or other IDs. The RFID keys are used for both identity and authentication, and most people aren't going to be able to keep them private, and under certain circumstances, no one will be able to.