By Will Young, Solution Architect, UnderwriteMe

The last blog post talked about how websites and leading insurtech SaaS providers can use certificates to prove who they are on the internet, but it’s equally important that users of a service can prove who they are. At UnderwriteMe, we make a large amount of data available to our clients, but we want to make sure that it’s only our clients who can access that data, and even then, it’s only the right people at each company. How can we allow clients to prove who they are when accessing our services?

When the web first took off, an extension to the Hypertext Transfer Protocol, or HTTP, was created. HTTP is the web’s main language and it’s used by both browsers, like Chrome, and web servers, which store web sites and deliver them to browsers. The browser would request the username and password from the client and send it along with each request. While this approach works in keeping out attackers with relatively limited time or resources, the Internet is more complex today than it was in the 90’s. When you load the Google email website, your browser is actually requesting over 140 different pieces of content. That’s because each element on the page has to be requested separately. There is a separate request for the page itself, each image on the page, any fonts used to display the page, and any other bits that make up a website. The username and password have to be sent on each request.

The sending of the username and password on each request is a problem in itself. Most IT systems have a feature where if you enter a wrong password too many times (normally at least 5) you get locked out and an administrator has to reset your password. They don’t do this just to be difficult. If the account wasn’t locked, then someone could try guessing the password until they got it right. Since the username and password are included on every request, and most of the time it’s with the correct password, those 124 pieces of content would give an attacker almost 600 guesses at the password. Obviously, this would require some very lucky timing, but if the attacker knew that a user was regularly browsing a website, they could make regular guesses and it might look like someone had just mistyped their password before correcting it.

Fortunately, we have better ways of securing websites today. Most of the Decision Platform isn’t the user interface. Rather, it’s a set of Web Services that use the same techniques and interfaces as the regular web but instead are designed to be interacted with by computers. They don’t return pictures and they don’t look nice when displayed in a browser. They just return data in a format called JSON, or JavaScript Object Notation, which is a way of marking up data in a way that’s easy for computers to read. This is fine, because it’s not a browser that’s talking to an Underwriting Engine, it’s another application – like the Protection Platform.

If there isn’t a user interface to enter a username and password, how can one system authenticate with another? We don’t want random people on the internet connecting to our clients’ Underwriting Engines and underwriting cases.

Just as we can use certificates to prove that a website is genuine, and that the public key that the server presents is the correct one, we can also use the same process again.

The server will have its own public and private keys that allow a browser to send encrypted data and allow the server to identify itself as genuine to the browser. Normally, these are enough, because determining who a user is happens in the application, and not as part of the web’s network protocols. We talked in the last blog about how the web uses a technique called Transport Layer Sockets, or TLS, to keep the web secure and stop people from being able to read traffic. There’s an analogous technique called mutual Transport Layer Sockets – abbreviated mTLS, that’s used to control who can access a service.

mTLS runs alongside TLS. The interactions are just as secure as with regular TLS, but also provide a way for websites to verify that a client is genuine. They can do this using the same technique that the client uses to verify that a server is genuine. This time, however, the browser isn’t just checking the server’s public key against a list of public Certificate Authorities. The server is also checking the client’s, and the client’s keys. When we issue a certificate for a client to connect with our servers, we keep a copy of the public key, and use it to confirm that the client has the private key.

This works well for server-to-server communications, but installing certificates in a browser can be a time-consuming process. And like all certificates, they have to be replaced every couple of years. So, for most websites, including the Protection Platform and Decision Platform user interfaces, a user logs in with a username and password and the website, with appropriate permissions for the user, appears. Under the hood, the webserver passes a token, or code, back to the browser when the user authenticates. This token tells the server that the user is legitimate. This process is often referred to as authentication, telling the server that a user is who they say they are.

These tokens have big advantages over passing a username and password with each request. The tokens are time-limited, so they expire after a short period of time, often just a few minutes. The protocols that provided the token also provide the browser with a way of refreshing the token, without having to pass the original username and password to the server. This means that an attacker has a very short period of time to guess the token before it changes.

Originally the tokens were just long, random strings. These are longer than most username/password combinations, and certainly would be harder to remember than a password. Today, the tokens are specially formatted to include new features. The tokens will not just have an expiry, but also a set of permissions. When a user authenticates with a username and password, they are given a token that the server has signed and possibly encrypted.

When the user – or the user’s browser – makes a request to the server with the token, the server verifies that the token is genuine and allows the user to access. We use this approach with our services that that have a human directly interacting with them, like the Protection Platform, or the Rules Editor. Sometimes, these services use Cocks’s formula, but others use a single key. The browser doesn’t need to know what the user can do, since all of the displays come from the server, so there’s no need to decrypt the token until it gets back to the server.

Both of these approaches are needed, depending on the problem to be solved. Between them, we can keep your data safe and let the right people access it.