In IT security, we often borrow ideas, theories, and experiences from the world of physical security. In this case, I would like to give the airport security people some advice from the world of computer security. Guys, whoever told you that security and ease of use are opposites was wrong. Dangerously wrong. Any time security comes without ease of use, any time you implement a device or procedure that makes it harder for your users to do what they’re trying to do, you’re more likely to be weakening your overall security than strengthening it.
In the 1980s, password policies were all the rage. We were trying to prevent attackers from guessing the passwords of legitimate users, and since we couldn’t trust users to choose strong passwords on their own, we implemented programs that checked password strength and prevented users from choosing ‘weak’ passwords. .
But users didn’t bother to remember those passwords, so the attackers learned that the payroll system password is on a sticky note on the monitor or in the top drawer of the desk. Other users were smarter than us: whatever password policy we set, there was a simple password strategy that fit this policy. Word that is not in the dictionary? QWERTY. No dictionary with numbers? qwerty1. At least 8 characters? qwerty123.
And the fight continues: Obligation to change every month? Ok, qwerty128 (Aug 8). This went on for about a decade, and finally the users won. So we introduced biometric identification, smart cards, USB tokens, and other devices that made it easier for our users to log in while also making our systems more secure. Wait, this made our systems more secure because it was easier for our users to log in.
In the 1970s, programmers connected with desktop terminals to the mainframe. Having natural impulses, they would sometimes leave their terminal and return after a few minutes. To prevent someone from “stealing” your terminal while you are logged in, the server would detect inactivity and log you out of the terminal. But programmers hate it when they’re writing their COBOL program and when they come back from the bathroom (or lunch) they need to log back in, open the editor, and find the line they were working on. Programmers are smart too, so they wrote programs to generate bogus activity that prevented the session from being logged out.
The solution came in the form of screen savers: instead of logging out of the terminal, just lock it. When the programmers return, all they have to do is type in the password and they are right where they left off.
A little over a decade later, this screen saver shows magnificent flying toasters. Suddenly it’s a great feature, and both users and security folks are happy.
As we pat each other 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 entire department is using pa$$word123 as their personal passwords, so others can use their stations when they’re away. Sooner than we think, this “policy” becomes part of new employee training. Users are happy, but security folks are freaking out: everyone in the department uses the same passwords, and those passwords are common knowledge (however, they exceed our password policy enforcement rules).
All this work for personal home directories and ACLs has gone down the drain. Users can log in to other accounts at will, and experts can shorten Authorization, Authentication, and Accounting to AAA, but our users also shorten it to no more than an F.
Fortunately, the desktop ‘switch’ feature was 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 would both be right: there is simply no contradiction.
Back to airport security. Bruce Schneier once wrote a great analysis of how El-Al airlines interrogate passengers. I fly on El-Al a lot and I also noticed something else: when airline security finds a cynical frequent flyer like me, someone who has heard the question “Did you pack your luggage yourself?” maybe a hundred times, he’ll stop the question and say, “you know why I’m asking all these questions, right? It’s because…”. His voice is not one of reprimand. They are clearly trying to invoke my sympathy. They are always successful: I have the feeling that they are here to help me, not obstruct me. That we are all on the same side. Give me enough credit as a thinking person to give me an idea why they’re doing this. In reality, they are recruiting me to help them find terrorists by helping them eliminate me as a possible terrorist. Sure, I’ll help you!
Most TSA workers are courteous and polite. But they do not invoke my sympathy. By taking the passengers’ water bottles and forcing us to take off our shoes, they make the passengers hostile and this, in turn, makes their job even more difficult. Now they have to deal with hostile passengers and long lines (which make passengers even more hostile) instead of concentrating on finding suspicious people or potentially dangerous carry-on luggage.
Unlike the programmers of the 1970s, these hostile passengers are unlikely to deliberately attempt to circumvent security measures. For example, I doubt anyone would intentionally try to smuggle water bottles on board. But I’m also sure that for many people seeing someone sneak aboard a tube of gel or a can of coke won’t get them to call the TSA. They will probably have the same feeling you get when you see someone ‘beat the system’, the same way the person who discovers a way to beat the password policy feels.
Making enemies of your users is not a good idea. The next time someone tells you that security and usability are at odds, 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 use, and that probably isn’t it. be a good conclusion. .