
Some token-based authentication systems use some signature mechanism but this is usually tied to the server who does the authentication signing the token and then handing it as it is to the user. This token is valid for a period of time, and the user can request another signed token from the identity provider. This is the case for oAuth2 for example.

One would obviously understand that if a such token is intercepted in any way, be it the refresh token or the authentication token, the attacker would be granted full access to the user account.
Below you can find a few attacks that can be made on such systems:

## 1. Cookie Stealing

![Cookie stealing illustration](/static/blog/how-secure-are-jwt-systems-cookie-stealing.png)

This type of attack relies on the fact that the cookies are being sent over the network as simple headers, part of the request. Meanwhile, the HTTPS protocol can alleviate some stress caused by this problem by encrypting the payload, one has to keep in mind the advent of HTTPS certificate miss-issuance and intentional certificate changing on people's machines. One should also keep in mind that the way that the HTTP requests are arranged, the cookies are part of the headers and thus being sent in a set portion of the request. This means that with certain cyphers and HTTPs TLS versions, the attacker only has to analyze which part contains the token header encrypted, by trial and error.

## 2. Man-in-the-middle cookie stealing

![Man-in-the-middle attack illustration](/static/blog/how-secure-are-jwt-systems-mitm.png)

This type of attack relies on the problem explained above where the attacker is already able to present the user with a certificate but the certificate is not the real certificate of the website they are visiting and, as an effect, the attacker; otherwise called a Man-in-the-Middle; is able to read and completely get hold of as well as change any of the requests or responses from and to the server. They can use this to literally get the refresh token or the access token and do whatever they please with them impersonating the user and making other requests on their behalf.

## 3. Replaying certain requests multiple times

![Replay attack illustration](/static/blog/how-secure-are-jwt-systems-replay.png)

For this type of attack, the attacker doesn't even need to decrypt or have the tokens; all they have to know is what a certain request contains and then repeat said request as many times as they need.

## 4. Changing the contents of the request

This requires either a man-in-the-middle attack or simply the attacker to change random bits of information on the request and get what comes out of it. Since the request is not signed, there's nothing to tell whether the request was indeed as the server received it.
As you can see above; the token-based systems have a bunch of attacks that can render their whole security completely useless to an attacker. The attacker can simply analyze the requests and with a bit of effort can impersonate a user. With all the attacks that were publicized lately where access tokens have been stolen from people's social media websites and then used to mount even worse attacks on them, one can already notice that this is no longer a thing that won't happen often enough for it to not be a problem. It is an issue and must be addressed.

## Ok, but what alternative we have? Signature-based authentication systems

All signature-based authentication systems are immune to the first two problems due to the way that every single request needs to be signed, but poorly designed ones can still be attacked with point 3. of the above list: "Replaying certain requests multiple times". This type of attack usually called a "replay attack" can render a request like Send 100$ USD to John into a possible attack where the request is being replayed multiple times and the server finds it valid.

[Zalter's](https://zalter.com) signature-based systems one can easily sign anything so there are certain pieces of information one can sign which render this type of attack impossible.

For HTTP requests, it is recommended to sign all the important headers that are required for the request to work: content-type for all HTTP requests, :path and :method for the HTTP/2 requests, or simply the method name and the actual path in the case of HTTP1.1 regardless of whether they were headers or not and any other important custom headers you may have sent. You can also sign the length of the request in order to prevent padding attacks (CRLF attacks). This latter option can also be done for Websocket requests.

The most important thing to sign, though, is a way for you to ensure the request can not be replayed and that's to either add a creation date and expiration date and if necessary add an idempotency id in order to allow your server to decide whether the request has been replayed or it's an old request and whether the request has already been acted upon.
In [Zalter](https://zalter.com) Identity, the requests we send from the client to our servers sign the date of the request creation as well as the expiration date, and this expiration date is set to be no higher than a few seconds to allow for high latency but not for a replay attack.


Type of attacks on the widely used token-based authentication methods. Are we really safe?

How Secure Are Token-Based Authentication Systems like JWT?


The current standard in authentication is some way of creating an authentication token which is then sent along with all the requests a user has to make during their visit on your website. Whatever was the way the token was created and however secure this token is, it’s still a token that, if stolen, can be used to impersonate the user. There have been lots of improvements to alleviate this problem ranging from refresh tokens, short lifespans, and various other things that made it more difficult but not impossible for a motivated enough malicious actor in the mix. The ultimate gold post was placing the “httpOnly” flag on the authentication cookies and making it more difficult for the developer to find out the authentication status in the application. For a while this has been quite fine and probably for many it is still a good enough security (if stealing the users cookie doesn’t create enough benefits to the attacker) but with the advent of “breaking for the fun of it” and with the company reputation at stake, attackers found creative ways to get their hands on this type of cookies.

Enter “Encrypted traffic inspection tools” which many enterprises install in their organization networks. These tools sell themselves as helping companies protect their intellectual property from their own employees and work by redirecting all company traffic through the tool ssl breaker which ends all the encrypted channel and re establish the connection using their own SSL certificate chain which happens to be a root certificate authority lately. There has never been an easier time for an attacker to mount a Man-In-The-Middle attack before in the history and these tools exist on the market for more than 10 years but they haven’t been so rampant in their use to mount attacks on users. Through the technology brought by these tools or through other malicious tools that work in the same exact manner attackers basically inspect the connection users have with their visited websites and can essentially “collect” the “httpOnly” cookies for immediate or later “consumption”. The stolen identities can then be used to mount other types of attacks or leaks and damage the companies in so many ways including stealing their so prized Intellectual property they were trying to protect in the first place.

Well then, you might say, if I don’t use such tools I’m not at risk. To which I can answer… I’m afraid you are! The simple existence of such tools, which, for some twisted reason, are legal and not considered a privacy breach, jeopardizes all online security. All it takes is one single malicious vector who has access to the network anywhere between the user and their visited website (be it one of the ISP employees, a computer virus on somebody’s machine in your network or anything whatsoever really that has access to that users network and the job has never been easier. Since everything on the internet at this moment relies exclusively on cookies from web app bank accounts to your social login, all of them are subject to stealing and subsequently impersonating the user to do the attacker's bidding, whatever is that the attacker might find profitable or even just funny to do. 

## So what is the solution then ?

At Zalter we’ve thought long about this issue and given that we already know a technology that has been tried and true for protecting the users, we developed our AKAS (Asymmetric Key GuardId System) for web, using military grade authentication systems that have always been used only in top security environments. We think that the current state in the market demands for these systems to be finally brought to the end users and we’re happy to say that we’re the first on the market bringing you the ability to have the strongest authentication system the technology can allow for!

There might be other solutions to the problem, but we think that at the moment all solutions must, in one way or another, use a form of what we’re doing in our system.

If you think you care enough about your company reputation, or you are already using such an SSL inspection tool or you’re just happier to know your users can safely authenticate from wherever they are. Zalter has the solution.

## What about end-to-end encryption then ?!

Well, this is going to be our next major product! Stay tuned and subscribe to our newsletter in order to get notified immediately as soon as we release it!


Why the current standards of authentication ought to change and how we did it.

Engineering

Aug 18th 2022

Valentin Popescu

Engineering

Nov 23rd 2021