The alternatives to password protection
Securing the desktop
Workshop In a world where it is possible to create credential-stealing malware and where users are supposed happy to trade passwords for a bar of chocolate in a railway station survey, we ask the question: is the era of password authentication coming to a close?
From the first time systems administrators looked to restrict access to applications, the “password” has been the default authentication mechanism. As we all know, this is far from foolproof.
Many companies use a common “shared secret” allowing multiple users to access a single account. Short passwords based on easily guessed names, which sometimes appear to be all that most users can memorise, are easily cracked.
Also it is fairly common for users to employ the ‘ultra-secure’ yellow sticky note containing log-in credentials where administrators weed out weak passwords by insisting on minimum lengths, character requirements and password lifetimes.
A case can be made that long passwords that are regularly changed lead to more security problems than a reasonable password that is kept confidential.
So what are the alternatives when protecting desktops and laptops?
It is now common to include fingerprint scanners with business laptops, and even some desktops. This provides users with a supplement to or an alternative to traditional password authentication systems.
Fingerprint recognition is now often found even on machines targeting the consumer market. Several vendors also include the ability to use smartcard authentication mechanisms.
Given that alternatives to password authentication on PCs are widely available in large parts of the installed base, why is it that the active use of any additional form of authentication appears to be sporadic?
One reason could well be that few enterprise systems management tools are easily able to exploit such technologies in the central authentication repositories, although this is changing.
A more likely rationale is that relatively few organisations consider the security of their desktop and laptop machines needs to be, or what form it should take.
In companies where security is essential, it is becoming more common, at least for some categories of users, to employ some form of additional authentication beyond the password, quite often by using a one-time-password system, such as a key-fob display.
This approach is valid, but it gives cause to ponder why such systems are not more widely deployed, especially as recognition grows concerning the requirement to protect the sensitive data commonly held on systems.
Is this simply down to the fact that some security companies have done a good job marketing one-time password devices to enterprise security teams who control the authentication requirements for certain classes of user? Have the PC and laptop vendors not promoted built-in smart card readers or biometric systems to add security options for the general user population?
Another factor is that few users are happy to employ additional authentication protocols, as many perceive these to add complexity to their log-on processes.
Research we have carried out over the years highlights that few people outside of IT and compliance / auditor functions understand the business requirements to secure their systems robustly.
Educating all users on the importance of IT security, and the steps they should adopt in their daily use of computers, has clear benefits by raising understanding, which ultimately helps improve all aspects of data security.
It remains to be seen if organisations will ramp up PC security authentication in response to the increasing raft of privacy regulations and other compliance and governance requirements will force.
This may well prove to be the trigger for adoption of secondary authentication mechanisms; and anyone that does not take steps may be placing the organisation at risk. Should they do so, we are likely to see a rapid take up of secondary authentication put in place alongside more robust password requirements.
As ever, we are keen to hear how you handle these matters, the solutions you have adopted and the challenges you have had to overcome.
Presence of a paired bluetooth device could be used as a second factor. I use (the excellent) Blue Proximity on my personal (Ubuntu) laptop, with the sensitivity turned right down - if my phone is not next to my laptop, it locks - when I put it back, it unlocks.
I'm sure it would be easy to use this as a second factor by setting it up to accept a short password when the paired device is present. A longer password should be available for device-free log-in in case you lose your phone on a screen-break.
Our major bugbear is the PCI-DSS standard; to comply, we have to enforce the strictest password policy, which involves (something like) a minimum 8 character password containing lower and upper case, numerals and special characters, changing once a month, and not the same to the last ten passwords.
Not only that, but these requirements apply to two or more systems (depending on department), meaning that even if somebody uses the same password across systems, the time of month that they change may be different.
Obviously, nobody short of savants can cope with this, and so in the REAL world we end up with shared passwords, obvious passwords (the most common is the person's surname, capital first letter, with 1! on the end), post-it notes, passwords kept in plain text on mobile devices, etc., etc.
I agree wholeheartedly that simpler password requirements would be more secure, as would alternative authentication methods (personally I like the idea of login name, simple password AND fingerprint), but the problem there is implementing it across systems, not to mention keeping ourselves legally safe in regards to PCI-DSS.
I can quite imagine the scenario if there was a PCI-DSS security breach. On one hand the vendor would be doomed if they hadn't enforced strong passwords; on the other, they'd be doomed if they had, and users wrote them down. There's no way to win!
Passwords can be counterproductive
Most of our computers are in a secure area that you need a specially permissioned access card to reach. We have lost more time (and money) because of lost admin passwords than we ever have from people messing with stuff they shouldn't have. In fact, I don't think we've ever had an incident of someone breaking a machine they didn't have the password for.
Anyone who has physical permission to access our floor in the data centre almost certainly has the passwords to damage anything they wanted to sabotage. Also, they could do plenty of damage without needing any passwords: loosen cables, break the emergency power-down glass, trip breakers, hit the halon release (or set off the smoke detectors), trigger the sprinklers (which the insurance company insist we have in case the halon doesn't contain a fire)... The list is long.
I think sometimes you just have to trust people.
Password requirements might be bad...
The worst, I think, is not the draconian password requirements, but the [insert-prefix-here]illion internal logins. When I turn on my computer, I need to type in a pssword for my computer hard drive, my computer login, the VPN, the remote machine I'm working with, its VPN, the source control password, the database password, and probably a few others to boot.
Passwords/logins are used for 1) protecting data and 2) tracking users. Too often, the data protected is pretty worthless, and/or inaccessible outside the company anyway, and the "tracking logins" could just be replaced with an IP address log. Even before removing the need for passwords, we need to remove the passwords we didn't need to begin with.
But one example.
In a previous job we had a room full of (mainly FreeBSD and linux) servers, and each box had an empty root password. Yes, empty, no password at all, and that was very deliberately done that way.
Why? Because if you're in that room you don't want to have to recall the root password, and you do want to get on with the job of fixing things.
Security relied on simple things: First, the wheel bit --which RMS by own admission thinks is a dirty capitalist bad idea, see "info su". I for my part think he is on crack and anyway we were a company not his hippie colony, so we reinstated the wheel bit through pam-- which blocks anyone but the designated people from "going root" and the rest has tailored sudo permissions. Second, most people simply had no access to most boxes and those that did, did so on the say-so of some executive, and we kept a paper trail of that at least. Never needed it but you never know. Third, physical security. The key to the server room was well outside the usual key system, only the sysadmins and the big box'o'keys in the secretary's keep had keys.
Of course, it wasn't fort knox grade by any means. But most "security" relies on the good will compliance and social acquiescence of the rest anyway. We're in the company to work together, and this does require a certain level of trust.
Of course this was a company of some 50 people and that is a different environment than a million person multinational. Still and all, if you look carefully and honestly at your requirements, you can get some surprising results.