Security is not the user’s responsibility

And should not depend on people doing everything right all the time…

(Like this article? Read more Wednesday Wisdom!)

Let’s start with some anecdotes. Three, to be precise…

Story 1: Many years ago I was consulting for a large bank, where I was working (among other things) on a web application for high value international payments. We didn’t process a lot of transactions, but they were typically in the millions of euros, in some cases even over a hundred million euros. One not very fine day, our web server’s SSL certificate expired. Panic ensued as customers were seeing pop up messages warning them about this problem. What were we to do? Smart people might have expedited issuing a new certificate, but unfortunately the bank’s internal IT systems were such a mess that nobody really knew how to request a new certificate at all, let alone expedite one. So instead the system administrators replaced the expired (but validly signed) certificate with an unexpired self-signed certificate. 

Now the customers got a different pop-up: Instead of a warning saying that the certificate was issued by a trusted third party but unfortunately one year and one day old, they got a message saying that the browser had received a certificate that was purportedly issued by “TheBank.Com” but which, all things considered, really could not be trusted. This is worse than the original problem…

But, people get weird messages that they don’t understand from their computers all the time, so most customers ignored the warning and continued to enter the website and send their international high-value payments. The younger and more impulsive me immediately went to the VP in charge of Global Transaction Services and told him that every customer who had clicked “Ok” and then proceeded to use the website should have their account terminated with extreme prejudice because our entire protection against man-in-the-middle attacks was based on the expectation that customers receiving that specific message should not press “Ok” and continue.

Neither for the first, and nor for the last, time, my sage advice was ignored…

After this episode was dealt with, there was some understandable anxiety that we might have other webservers with certificates that were about to expire. “Do we have a list of certificates and their expiration dates?” somebody in charge asked. “Nope”, was the answer. To solve this, I wrote some Java and shell script to connect to all of the publicly accessible bank websites, harvest the server certificates, and produce the much wanted list. The next thing that happened was that the bank’s security people paid me a visit and accused me of hacking their systems to obtain this confidential security information. I guess they quite didn’t know or understand what the “public” in “public key encryption” means…

Story 2: A few years before that specific episode, I made good money teaching courses on Netscape products, including the Netscape Certificate Server. This now long forgotten product could be used to create your own internal Certificate Authority (CA). As you will hopefully agree, implementing your own CA requires a decent understanding of how certificates and the associated encryption standards work.

Fortunately, most people attending this course had already gone to the Netscape web and mail server courses, where SSL was covered in some detail. However, whenever I facilitated the Certificate Server course, I always had to go over the basics of SSL again because most attendees (correctly) were of the opinion that their understanding of all things encryption might do with a bit of touching up.

Apart from issuing certificates, the installed Netscape Certificate Server used quite a few certificates as well: A root certificate for its certificate authority, another certificate to issue certificates with, a regular SSL certificate for its built-in web server, and maybe a few client certificates for identifying the administrators. Each of these certificates was associated with a private key that was encrypted with a password. When using the certificate server, password dialogs would pop up left, right, and center whenever the students needed to login somewhere or when the browser or server needed to decrypt a private key for signing purposes. When this happened, I would ask the attendees why we were logging in or which private key we were trying to unlock and, if so, why. Nobody ever got it right… Therefore, in order to ascertain some progress throughout the course, we taught the students to use the same password for every administrator account and private key, thereby ensuring that whenever that password leaked, the entire system was compromised.

Story 3: Some time ago I lost the encryption key of a production system due to a cloud provider eff-up that had led to the loss of an entire production Kubernetes cluster (including the Kubernetes secrets). I was just about to admit total defeat when I, in a last ditch attempt, tried the encryption key we used in our development environment. And, lo and behold, it worked! Apparently, when I created the production system I had copied the entire setup, including the encryption key, from the development environment to the production environment. Lucky me! But also: Bad bad me!

Bonus story: A few years ago, flyers started appearing in the Google office in Zürich offering cool swag in return for participation in a survey about a new yet-to-be-launched product. People understandably whipped out their cell phones, scanned the code, and filled out the survey. Instead of some cool swag, they got a stern email from the security department that you shouldn’t scan random QR codes and then give away data; the whole thing had been an orange team exercise to increase security awareness.

More than a decade later I worked at a secretive startup and one day badly worded flyers started appearing in the office that announced that we finally had some cool swag and everyone was invited to go to a non-company web site to order some. I went there and got a suspicious single sign-on error instead. I thought about it and, remembering the previous episode, wondered if I had just been pwned… I asked around and the answer was “nope”:The website wasn’t active yet; either the flyers had been distributed too early or it was so badly written that it wasn’t obvious that the site would go live only on Friday.

When the website did go live it immediately crashed under the load. The swag-team shared a screen-shot of the product catalog web page and instructed people to manually construct the REST ordering URL. That worked and three weeks later I got a box shipped to my place with some cool swag.

And here my friends, you see the problem of the current state of IT security: It is too complicated, neither the average user nor the average system administrator (or even the average security professional) truly has a good handle on it, and overall system security usually depends on everyone doing everything right all the time.

That last thing is simply too much to ask of people and consequently we live in a world with permanent security breaches big and small. Because of that, I have been under constant identity theft “protection” from the moment I became a resident of the United States. Literally, one month after starting at Google in Cambridge MA, I got a letter from our HR department saying that a vendor had managed to lose a lot of our PII, including names, addresses, dates of birth, and of course, social security numbers.

By law, Google had to offer me “protection” against identity theft for a year. “Fortunately” for me, after that year had run out, Equifax (a credit reporting agency) had managed to lose the information of some 147 million people, me included. Since then, I have been a semi-permanent victim of some form of data loss or another.

As I write this, the lovely Mrs. Wednesday Wisdom got a letter from TicketMaster where they told us that they lost some of our information and here is a code for another year of “protection” against identity theft.

Late breaking news: After finishing the first draft of this week’s article, I got a message in my news feed that stated that National Public Data has been hacked and apparently lost full address details going back thirty years and social security numbers for almost three billion people!

Security is so complicated that even if you do understand the ins and outs of it and want to do the right thing, it is just too hard to do it all right all the time.

Have you ever tried to set up SSO for a web application using AzureAD and Terraform? It took me days and multiple attempts to get that right using an unholy combination of substandard documentation and StackOverflow. I couldn’t get it to work until I realized that after all of my “infrastructure as code” setup I still needed a security admin to click on something in the Azure Portal. Plus to get this particular setup going, I needed to copy a secret from somewhere and paste it somewhere else, so that secret is now probably in my command line history.

We have outsourced security to the end user. I have so many passwords and pin codes that even with the help of a password manager it is impossible to keep them all unique and good. On top of that, I now have four authenticators on my cell phone and one of my bank accounts uses a separate authentication application that is only installed on a five year old cell phone that I keep around for just that purpose because I have not been able to move it to my new phone. I got master passwords, fingerprints, and face recognition. Whenever I need to log into my Google account, it will either ask me for a code from an authenticator app on my phone, or it will send me a text message with a code, or it will pop up a dialog on one of my Android devices verifying it is me. Which one is it going to be today? Who knows?

This is relevant because good security depends on it being simple to detect an anomaly and that has become impossible.

Some of my passwords need to be at least eight characters. Some passwords cannot be longer than eight characters. Most passwords need a special character. Some passwords cannot deal with certain special characters. So I regularly need to reconfigure my password manager to restrict the length of the generated password or the character set used.

It also doesn’t help that sometimes the GDPR inhibits the use of more secure authentication technology for privacy reasons.

On top of that we are training people all the time to identify themselves constantly or to ignore weird messages from their computer that they have no hope of understanding. Additionally, many organizations manage to make half of their legit communication look like outright phishing attempts. I need to show my ID all the time (even when going to the doctor), the bank calls me and asks me for my social security number, companies send me badly worded emails from non-standard sender addresses and redirect me to websites not in the main company domain.

They are actively conditioning me to trust random things on my phone and on the Internet.

We put the onus of staying secure with the people who are least likely to be good at it: The non-expert end user. They need to choose great unique passwords, keep them safe, detect phishing attempts, not use public WiFi (which is BS security advice that is still preached daily), use VPNs, not use free VPNs, not click on links, not scan random QR codes, not enter data in AI chatbots, not download attachments, not divulge confidential information on the phone, use privacy screens on their laptops, configure multi-factor authentication, not login on public computers, not post selfies with their boarding pass, not install random apps, not trust random people who call them and definitely not trust random people who ring their doorbells.

If your security depends on people doing the right thing each and every time, perfectly, without any slip ups, things are bound to go wrong, especially if there is no consistent right way to do things. How do we expect people to deal with this?

I am afraid I have no answer for this. Good security is effective, elegant, and devilishly hard to design and build. Ideally speaking we should have consistency across all applications and platforms and that is hard for a species who haven’t even figured out which slashes to use as path separators in a filename or on which side of the road to drive. My only hope is that we figure out the gene for honesty and implant it in every embryo. It will take a generation or two, but then this problem is finally solved.

And in that world, my friends, I will be a stainless steel rat.