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
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
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
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 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 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.
So what are your thoughts about this? Let us know in the comments down below.
Top comments (0)