Security by obstruction
In IT security we often borrow ideas, theories and experience from the physical security world. In this case, I’d like to give the airport security people some advice from the IT security world. Guys, whoever told you security and usability were opposites was wrong. Dangerously wrong. Whenever security comes without usability, whenever you put in place a device or procedure that makes it harder for your users to do what they’re trying to do, you are more likely to be weakening your overall security rather than strengthening it.
In the 1980s password policies were all the rage. We were trying to prevent attackers from guessing legitimate users’ passwords, and since we couldn’t trust the users to choose strong passwords by themselves we put in place programs that checked the passwords strength and prevented users from choosing ‘weak’ passwords.
But users couldn’t be bothered to remember those passwords, and so attackers learned that the password to the payroll system is either on a post-it note on the monitor or in the top desk drawer. Other users were smarter than us – no matter what password policy we set in place, there was a simple password strategy that conformed with this policy. Non-dictionary word? qwerty. Non-dictionary with numbers? qwerty1. At least 8 characters? qwerty123.
And the fight goes on: Force to change every month? Fine, qwerty128 (8 for August). This went on for about a decade – and eventually the users won. So we introduced biometric identification, smart cards, USB tokens and other devices that made it easier for our users to login, yet made our systems more secure. Wait – this made our systems more secure because it was easier for our users to login.
In the 1970s, programmers would connect with desktop terminals to the mainframe computer. Having natural urges, they would sometimes leave their terminal and come back after a few minutes. To prevent someone from ‘stealing’ their terminal while it’s logged in, the server would detect inactivity and log off the terminal. But programmers hate it when they’re in the middle of writing their COBOL program and as they come back from the bathroom (or lunch) they need to log in again, open the editor and find the line they were working on. Programmers are also smart – so they programmed programs to generate fake activity that prevented being logged out.
The solution came in the form of screen savers – rather than logging off the terminal, just lock it. When the programmers come back, all they has to do is type the password and they’re right where they left.
A little more than a decade later, this screen saver shows magnificent flying toasters. Suddenly it’s a great feature – and both the users and the security people are happy.
As we pat ourselves on the back users begin to realize that if John left work and Alice wants to use his (now vacant) station, she can’t – because it’s locked. Suddenly, the whole department is using pa$$word123 as their personal passwords, so that others can use their stations when they’re away. Sooner than we think this ‘policy’ becomes a part of new employee training. The users are happy, but the security people are going nuts – everyone on the department is using the same passwords, and those passwords are common knowledge (yet they beat our password policy enforcement rules).
All this work for personal home directories and ACLs is down the drain. Users can log into other accounts at will, and Authorization, Authentication and Accounting may be shortened by experts to AAA but is also shortened by our users to no more than an F.
Luckily, the desktop ‘switching’ feature is introduced and makes it possible for two people to share the same PC without knowing each other’s passwords. Some people will call this a ‘usability feature’, but I would call it a ‘security feature’. We’d both be right – there’s simply no contradiction.
Back to airport security. Bruce Schneier wrote a great analysis once on how El-Al airlines does passenger questioning. I fly El-Al a lot and I noticed something else, too – when the airline security person finds a cynic frequent flyer like me, someone who has heard the question “did you pack the luggage yourself” maybe hundreds of times, they stop the questions and say: “you know why I’m asking all these questions, right? It’s because…”. Their voice is not reprimanding. They are clearly trying to invoke my sympathy. They always succeed – I get the feeling that they’re here to assist me, not to obstruct. That we’re all on the same side. That they give me enough credit as a thinking person to clue me in on why they’re doing this. Actually, they are recruiting me to help them find terrorists by helping them eliminate me as a possible terrorist. Sure, I’ll help out!
Most TSA workers are courteous and polite. But they do not invoke my sympathy. By taking passengers’ water bottles and forcing us to take off our shoes they make the passengers hostile, and this in turn makes their job even harder. Now they have to deal with hostile passengers and long queues (that make the passengers even more hostile) rather than focus on finding suspicious people or potentially dangerous carry ons.
These hostile passengers, unlike the programmers from the 70s, are unlikely to try and purposely circumvent the security measures. For example, I doubt that anyone will be trying to intentionally smuggle water bottles on board. But I’m also sure that for many people seeing someone else sneaking a gel tube or a coke can onboard won’t make them call the TSA. They will probably get that feeling you get when you see someone ‘beat the system’ – the same way the person that figures out a way to beat the password policy feels.
Antagonizing your users is not a good idea. Next time someone tells you that security and usability are on two opposites, tell them that the corollary is that ordinary users who want to use the system are the enemies of the security people who try to limit this usage – and that’s probably not a good conclusion.