

Saturday, 17 October 2009

Password Length, from zero up?

How long should my password be?

In the authentication space, short of multiple-factor (more of which later) nothing seems to exercise the security community as much as the subject of password strength, in particular the question of how long a password should be, and if implementing password rules, what minimum length to set.

A common misconception is that there is a single correct answer. This discussion humorously illustrates that idea, with some participants simply asserting "6", others "12" and some invoking Douglas Adams.

But like all security controls, the decision must be a risk-based one. Fortunately at least one poster above demonstrates this concept thus: "Without context, it's an impossible question". I agree, is this an internet banking site? Your twitter account? An internal, corporate room-booking system?

A practical security control has to implement security without adversely affecting usability, or human nature says people will circumvent it to restore usability. In the case of password length and strength, forcing long and complex passwords on users will increase the likelihood of them using repeating patterns and guessable values or writing them down or storing them electronically, thus increasing the chance of compromise and defeating the control. Also it increases the likelihood they will forget and need a password reset, increasing helpdesk costs and further increasing risk by requiring more privileged users on the helpdesk.

As for the context, I say if it is a low-risk system, why have a password at all? That room-booking site is only available on the corporate intranet, so only authorised users can get at it anyway. And the risk posed by impersonation? Someone can book rooms under another's name. Big deal. So for this system why authenticate users? Let them identify themselves, but leave passwords out of it, trust the users to play fair. (Ideally the application should defer to already authenticated credentials e.g. via LDAP but usually that's too hard to implement - most systems just request user and password out of the box).

So the minimum password length should sometimes be, er, zero. Sometimes, identification and trust is enough. Sometimes you can risk not authenticating, strongly or otherwise. Remember, in an organisation with multiple disparate systems, users will share passwords across systems, thus their passwords are as safe as the weakest system. So forcing them to use a password on the room booking site might expose a privileged account password used elsewhere. If that corporate room booking system is externally hosted, you have little control over it, and right now someone might be reading your privileged account passwords and working out how to exploit them.

Set password strength rules appropriate to the risk, and don't think that longer and stronger is always better, remember human nature and don't risk frequent password resets or force users to write down passwords. Stay Practical.

Saturday, 10 October 2009

Adobe Zero Day - Too Much Functionality?

Praetorian Prefect Adobe to release critical update on patch Tuesday

I'm constantly staggered at the frequency of the reporting of vulnerabilities in what should be simple applications. This attack uses heap spraying in Javascript to execute malicious code that installs a backdoor. My eyes alighted on the phrase "JavaScript" in the notification. When did Adobe Reader gain JavaScript capabilities?

By most users, Adobe reader is used just for opening PDF documents, which themselves for the most part are static text and images. However the latest version of Adobe Reader, version 9.1 is a 35MB download, and it contains support for JavaScript and Flash and lots of other things that enable "feature-rich content". I doubt many people want animation in their PDFs, and one point of converting to PDF for many is to strip interactive MS-Office features such as tracking data and macros.

A humorous discussion of the issues can be found here on this NZ technician's blog, but seriously, practical Application Security starts with matching the product to the requirements. If you are just adding features for fun (or in Adobe's case, almost certainly to use the freeware to cross-sell other apps - they now sell Shockwave and Macromedia's old product lines) then you're failing your customers. Given Adobe's market penetration, their product's subsequent contribution to the global virus load makes this unforgivable.

Practically Secure recommends SumatraPDF - a 1.2MB downloadable PDF reader that just, er, reads PDFs.

Wednesday, 7 October 2009

The Threat from Within

The Threat from Within.



Tuesday, 6 October 2009

Practical Security Measures

Welcome to my blog. Here I will share my thoughts on Information Security, and my particular slant on it - implementing genuinely practical controls.

Too often security measures are conceived in ivory towers and placed on virtual "shelves" to gather dust and please a passing auditor or tick a compliance box.

To really improve security all controls must take care of the Human element, be practical and really impact positively on day to day operations, be valued by individuals and championed by Managers.

A control that adds business value is one that will be operated effectively. Let's discuss that.