We are at a turning point in the ongoing history of computer security. The password has long been the preferred method of securing our access to everything in the computing world but it has failed to stand up to modern threats. Today’s news is filled with stories of accounts being hacked, online bank accounts being emptied, and customer information being leaked. The result is billions of dollars in losses due to fraud and reputation damage, and at a more personal level, the terrible experience of having your identity stolen. But there is light at the end of the tunnel. Computer security experts have been working to develop new ways to secure our online interactions. In this series we will explore how we got here and where we are going next, while keeping the content approachable for a non-technical audience. (This means we’ll minimize the use of confusing jargon!)
Part 1: A Brief History of the Password
2021 marks the 60th anniversary of the password. Passwords were invented at MIT in 1961 to allow researchers to share time while keeping their accounts private on the expensive and exclusive university mainframe computer they shared. Each person had a secret word they gave the computer when their account was created, and repeating the same secret word the next time they accessed the computer would (at least in theory) prove that it was the same person logging in.
Passwords seemed like a good way to keep accounts private and secure, but it didn’t take long for someone clever to find a way around them. In 1962, Ph.D. researcher at the university figured out how to print the password file so he could use other researcher’s computer time. This is the first recorded incident of a computer breach.
Passwords and the Internet
Fast forward a few decades and we see the introduction of the Internet and the explosion of online sites and services it made possible. The shift to always-accessible online services had far-reaching impacts, but two side effects had a particularly strong impact on computer security: first, each time a person joined a new site or signed up for a new service they would need to provide information to identify themselves, and second, they would need to supply a password to secure the new account.
As the number of online services steadily increased, there was a corresponding proliferation of identity information and passwords across the Internet. From an end-user perspective this caused a lot of frustration. Today, the average North American has over 90 online accounts, with passwords for each. Remembering this many passwords is not realistic for humans, so to cope with the problem many people use the same password across many (or all) sites, or come up with a pattern that is easy to remember (but also easy to figure out). The problem, however, is this makes these users very vulnerable to hacking: it’s easy to download a script that will read a list of usernames and passwords and test logging in to millions of websites, looking for a successful match (this is called password stuffing). All it takes is one bad website administrator or one data breach leaking credentials and the bad guys can gain access to all accounts that use the same password. The other alternative is to use a password manager such as LastPass or 1Password to generate random passwords and remember them for you under a single master password. But what happens if that master password gets compromised?
Single Sign-On (SSO)
In an attempt to resolve these shortcomings, a number of products emerged in the late 1990s and early 2000s called web access management or WAM for short. These solutions required an agent (this is a small application) to be installed on web servers, and these agents would intercept web traffic, log users in with a central server, then set a cookie in the user’s browser so subsequent requests would be marked as authenticated and allowed through. (This is an oversimplification, but I promised not to be too technical so I will leave it at that.) These new solutions were the beginning of web single sign-on or SSO, and if you have ever worked for a medium or large organization you’ve probably heard the term. Once an organization setup a WAM product, they could protect all their internal websites with agents, their users gained the convenience of signing in once with a single password.
This was all well and good if you were working at a company with an expensive, centralized web access management system, but it didn’t do much to help workers who wanted to access applications at another company or regular consumers trying to access online services. (In fact, dealing with customer identities was seen as so complex that it spawned a whole separate subdomain of IAM unimaginatively named customer identity and access management or CIAM). This leads us to our next evolution in passwords and online access.
Around 2002 a new standard appeared called Security Assertion Markup Language (SAML for short, since we technical folks love our three- and four-letter acronyms) with the goal of enabling organizations to share identity information through a trust relationship. The organizations involved could form a federation, allowing one organization to assert (vouch for) the authenticity of a user to the others. The new standard unlocked the ability for you to login once and access many services which could even be hosted by different companies. Because your home organization (called the identity provider) could assert your identity to the service providers, there was no need for the service providers to store a copy of your password. The identity provider could even share information about you behind the scenes, which at first seemed like a really good idea. (Spoiler alert: it wasn’t!) Incredibly, SAML (now in its second incarnation, SAML2, since 2005) is still commonly used today, but is relegated to intra-organizational single sign-on use cases where the issue of privacy is not a concern. This serves as an example of how slowly the world of information security adapts and evolves.
As the standard started to become widely adopted, privacy advocates were quick to criticize that sending identity information in this way without the user’s authorization was trading privacy for convenience. To address these concerns as well as to add support for new types of applications such as mobile apps, additional standards were introduced over time. I will get into more detail in part 2 of the series, but eventually most services adopted the newest standard called OpenID Connect (OIDC). Like SAML, OIDC allows service providers to trust the identity of a user based on the authentication performed by an identity provider, but also specifies that users must grant their consent before identity details are shared. Most readers will have used OIDC perhaps without knowing it by name – if you’ve ever logged into a website using your Facebook, Twitter, LinkedIn, or Google account, you’ve used OIDC. Today, most consumer-facing websites and services offer the OpenID Connect method to users as a convenient way to sign up or login to their services.
In the second part of our series I will get into some of the problems we face with the current incarnation authentication controls, and talk about innovations that have been introduced to address them. In the third and final part of the series I will discuss forward-thinking ideas in identity and access management such as self-sovereign and decentralized identity and introduce BlokSec’s solution.