To ensure a corporate network is fully secured against today’s many cyberthreats, the authentication of any person wishing to access it is an absolute must. Verifying that someone is a legitimate user and not a hacker or cyber-criminal is a fundamental piece of the information security puzzle.

Yet, authenticating users has traditionally been a distinctly user un-friendly process, requiring passwords to be remembered, keys to be transmitted and typed in, and other burdensome hoops set up for users to jump through.

Thankfully, a modern, next-generation authentication solution offers a much simpler experience for your users. In fact, in involves no user action at all.

To understand how revolutionary this new approach is, let’s clarify a few oft-heard questions to dispel common misconceptions about authentication.

Question 1:
Does remote authentication need “multi-factor authentication” (MFA)?

State-of-the-art remote authentication uses public key cryptography. CERT and FIDO authentications don’t have shared secret (data known only by participants in a communication, such as a password), are phishing-resistant and provide the security level other methods like SMS and OTP cannot.

Public key-based authentication only needs a securely protected key. It doesn’t need multi-factor. In fact, none of a user’s knowledge nor inherence affects the protocol. The endpoint device can do that job perfectly without any other “factor,” be it from users, a crypto device, a phone or anything. This means it is unbreakable. All computers in the world combined would require years to break it.

Answer:
Remote authentication doesn’t rely on multi-factor authentication. The endpoint alone can do it perfectly.

Question 2:
Who is the client in the client-server authentication process? The user or the endpoint?

While the user should get the services, they should not be the entity performing the authentication with the server. As explained above, users don’t have the capabilities to be nearly as effective as the endpoint with cryptographic operation and secure key storage. A user’s knowledge (what they know) or inherence (what they are or do) are not suitable for remote authentication where everything is data and shared secret is not effective.

On the other hand, today’s endpoints are equipped with crypto-chip technology, meaning your company can be sure that no one or no thing can “steal” your endpoint’s identity. This feature – in which only your endpoint can access corporate services – could prevent most account takeovers today as hackers would have to physically visit your company’s premises and steal the laptop.

As such, it is advisable to consider the “client” in the client-server authentication something which includes the endpoint, not just the user.

It’s also useful to consider how long a session should last after the (client-server) authentication takes place. If the session lasts longer than, say, one minute, the email server can download the user’s email on that endpoint, and the server should verify that the endpoint is still authentic (in other words, still the same endpoint).

Note the use of the term “endpoint.” No matter with whom the authentication took place, the server maintains the connection with the endpoint. In fact, most or all servers today place a token or cookie on the endpoint and uses it to verify the endpoint – to “re- authenticate,” if you will.

Let’s realize how significant this is. While the authentication might take place once a day, the “keeping the session,” “re-authentication,” “maintaining the authentication state” happens many, many times more often. What does this tell us?

The servers have been using the endpoint as the “re-authentication,” or to verify things, before continuing to give services after the initial login. Why not use the endpoint for the login as well? Note that the endpoint will have already authenticated the user. Here, the endpoint is the combined identify of “device and user.”

If the authentication did not use the endpoint, there is a problem with the association between the authentication and the endpoint. The newer “passwordless” solution that uses a phone makes it easier for the user by not requiring them to read a key from the phone and type it on the endpoint. But this also removes the association and presents a problem. When the association is missing, attacks can occur, such as a push attack.

As a result, it is advisable to use the endpoint over the user. If the solution uses an out of band (OOB) phone instead of the user or endpoint, even more vulnerabilities are created. An OOB phone is effective as secondary factor but should not be used as the primary factor.

And verification will certainly be needed if hours have passed. While the user should receive the services, the server never really talks directly with the user. The data exchange is always between the server and the endpoint. As a result, it makes the most sense for the server to authenticate and maintain the authentication with the endpoint as the first, main entity.

So, to answer our second question, Who is the client in client-server authentication – the user or the endpoint?

Answer: The endpoint!

Question 3: Now that we have established that the endpoint can do it all, are users superfluous?

I’ll provide the answer up front: No, they are not superfluous.

Here’s why:

By distinguishing the two authentications, the user from the endpoint and the endpoint from the services provider, the smart endpoint can be allowed to take care of authentication, eliminating the need for any user action. No action!

The user, though, still has an important role to play. The endpoint has the duty of authenticating the user (or users, as it can be shared among multiple individuals). The endpoint, however, will need a user to unlock it before it can assume the combined identity of “device + user.” When the user logs out and another user logs in to the endpoint, the endpoint will no longer represent the first user but rather, the second person.

Now that the user is involved, multi-factor authentication can be employed, such as a PIN, biometrics, or some token, like a USB or a phone. But it’s for unlocking, for continuous checking, not solely for services providers. Users will continue to log in to the endpoint, with more MFAs if desired.

The endpoint continues to be smart here. More than just verifying a user’s presence, the endpoint can see a user’s intention when the user accesses the services.

The benefit of distinguishing the two authentications, and the fact that the endpoint itself can perfectly authenticate to the server, is that you will no longer need to do anything to achieve secure remote authentication. You won’t need to use long passwords, nor

SMS or OTP, because your endpoint can do it for you, securely.