I’d like to shed some light at the process of Authentication since it’s a fundamental building block in creating secure tools that need to communicate with other actors over the network. When tools and/or users interact with one another – e.g., through a web browser – both ends of the interactions need a way to make sure, they’re communicating with the right party. Some bad actor might for example create a web page that looks like your bank’s online banking portal. With additional DNS spoofing you might be connecting to the wrong website. When you’d be trying to log in you’d be prompted for username and password. If you entered them on that phony web page, you’d provide them to the attacker. It’s imperative for your browser to be able to make sure, that this is not the case here.

When you’re using you’re company’s internal tool, for example a web page for requesting time off, the web tool must be able to identify you. It has to know which employee is requesting vacation. It’s also going to have to identify your manager when he or she will be reviewing that request – only your manager should be able to view and approve/reject it. In case of such tools we actually have 2 processes:

Authentication – tool is identifying who is requesting vacation time

Authorization – When your manager attempts to view pending time off requests, is she/he allowed to view your request?

In this post we’re going to focus on Authentication.

Another example: software developers probably have a tool in their company that allows them performing code reviews. Again, the tool has to know who the developer is – it has to know which reviews are available for that person and which reviews they are allowed to approve/reject/merge.

In order to figure out, who you are, some of those tools require you to log in. Sometimes providing username and password is enough. Other times, you may need to have additional piece of electronics, like cellphone or Yubikey. However, some web tools don’t ever require us to log in, yet still they know who we are. For example at a company I worked for a tool for code reviews is that kind of web application. I just open its web page and immediately I see what reviews are pending my approval. What Reviews I’ve submitted and are pending others’ approval. I never have to log in, yet the tool knows who I am.

Another example: one of the largest Swiss/American banks, all employees had a smart card. Whenever one wanted to use a computer, they would insert the smart card into the card reader connected to that computer, and they’d be able to log in with their username and smart card PIN.

Three types of Authentication

In all cases different combinations of 3 basic forms of authentication are being used. In some cases only one of them. In others for improved security, 2 or even more.

What you know

If the tool you’re using is asking you for username and password – this is exactly that approach. Only you are supposed to know the username and password. Thus, the system assumes you are who you claim to be if you know the username/password.

What you have

If you enable Multi-Factor Authentication on PayPal, you’ll be asked for a username and password and then PayPal will text you a 6-digit code to you cellphone. You’ll be then asked to enter that code when logging in.

Asking you for that code is exactly that second approach – only you are supposed to be in possession of you cellphone. You prove that you are who you claim to be by proving that you have the cellphone with you. Otherwise, you wouldn’t be able to get the code, PayPay texted.

The smartcard at the bank example I just mentioned – this is combination of What you have (the smartcard) and What you know (username and PIN associated with that particular smartcard).

Who you are

Those are implemented by all sorts of biometrics. For example your laptop or cellphone might have a fingerprint scanner that you can use to unlock it. Your cellphone/laptop might be using its camera to scan and recognize your face or just eyes.

Those are examples of “who you are” approach.

What is what

If only one of the above methods is used at a given time it’s called Single Factor Authentication. Proving that single thing you’re asked about is enough to authenticate you. If that factor, however, is compromised (e.g., attacker gets hold of your username and password) they can impersonate you. To reduce the risk of an account being compromised that way a system might require more than one of the above approaches. Taking PayPal as an example – when you enable MFA, 2 of the above approaches are being used. The What you know factor (username and password) and the What you have (6-digit code that’s being texted to you cellphone when you’re logging in).

Having the standard login: just username and password is convenient. Why should I care about the fuss of using my cellphone or whatever for my 2nd factor? I use strong passwords and never log in from computers that I don’t own and fully control. Is the hassle of using additional authentication factor worth it? That is really important question. The answer might be different for different people. For example single factor might be enough for me for an unimportant public web page. Although probably would make much more sense for my online banking account.

What about a large enterprise-scale company? For individuals answer will depend on many personal factors. However, for large companies it’s going to be much more coherent. These need to deal with common problems related to securing their services at scale. They employ a lot of people. Some of them, thousands. At that scale there will be people who don’t care or even don’t know enough about security to create strong and hard to guess and thus crack passwords. Even if all those people had strong passwords there would still be a risk of for example laptop of one of the employees being compromised. Introducing 2nd authentication factor increases security at scale big time. Big tech companies like Google or Amazon use MFA internally to secure access to internal services. Some big banks do that too. Let me explain how all that works.

Web tools that automatically know who I am without any signing-in process

Even though here only one factor of authentication is being used it’s still interesting to understand how it works. This approach is the most convenient for the users (employees), but obviously less secure than MFA approach.

When you’re opening a webpage of the tool that is using this method in your web browser, the first thing the browser does is performing SSL handshake. Simplified flow diagram:

The first thing that happens is Client sends HELLO message. Part of it is crypto-related metadata – client informs what cipher suites it supports (what cryptographic algorithms it supports and is willing to accept to use). Server responds with its own HELLO message. It also sends its supported cipher suites. Server also always sends its X.509 certificate that contains information about the server. Without getting into too much detail, this bundle of information is enough for the client to cryptographically prove that server is indeed who it claims to be (that this isn’t any impostor). From the online banking spoofing example above – when you’re opening your bank’s page through HTTPS (URL starts with https://), browser establishes TLS connection utilizing that SSL handshake. After obtaining bank’s server certificate, it validates its authenticity.

Next – and this is an optional step – server requests client to also present its own X.509 certificate. This step is unique for this type of authentication. In general, it is optional because the client has to have a valid certificate in the first place. It’s not obvious to non-technical person how to obtain trusted client certificate and install it in their operating system or web browser. That’s why public web services, like GMail for example, will use different means of authentication – standard sign-in process using username and password. However, your work computer will likely be managed by your company’s IT department. They do know how to install such a certificate in your browser, that’s why in corporate world it makes much more sense. At this point the client (your web browser) after verifying cryptographically if the certificate presented by the server is authentic and trusted, it responds to the server sending its client certificate. Server does the same verification on its end. Since client certificate contains information about the certificate holder (you), at this point server knows who you are – you’ve been authenticated. Now, having identified you, the server may allow or reject your requests (authorization).

Tools that redirect you to another page and require using hardware key

As I said to reduce the risk of unauthorized access to the tools, “big boys” like Google or Amazon also use what you have method. You’re given a hardware key (e.g., Youbikey I mentioned above), and you have to use it during authentication process. Here’s the workflow for it:

1. You open the link to your internal tool
2. The tool redirects you to your company’s internal authentication site
3. The authentication site asks you for username and password (what you know)
4. The authentication site asks you to use your hardware key (what you have)
5. If both authentication method succeeded – you entered correct username/password and used the correct hardware key, you’ve been successfully authenticated.

That is a high level view. In more details, it looks something like this:

The above diagram is pretty generic and lacks certain details. For example the cryptographically signed authentication cookie might be a custom-formatted home-brewed design. E.g., something like:

HMAC:session_id

where HMAC is some concrete flavor of the standard. For example using SHA256 on a symmetric secret and generated session ID:

HMAC_SHA256("My company's tightly kept secret", session_id)

And session ID could be some random UUID. E.g. b3a244e0-cc15-431b-b20e-295541bd599f. So given the above secret and session ID, the cookie would look like this:

65ba57a0a779cb8e6f7d1197df83b748f398331234db50f7b02066511555cd68:b3a244e0-cc15-431b-b20e-295541bd599f

More likely, though, an established standard would be used. For example JWT.

What about personal MFA use-cases?

You might be wondering, what about securing access to my personal account? E.g., GMail, GitHub/GitLab? I’ll write a separate post about options for securing your own personal accounts with various forms of MFA. I’ll also explain why you might want that enabled.