What’s wrong with JWT and token based authentication in general?

4 min readFeb 27, 2018

This article is inspired by known cases of JWT and tokens in general being misused both against stated designers’ assumptions and against security level tokens can provide. Also, there is intention to raise awareness of thinking people.

General problem of communication through untrusted peers

There is a very long history of seals, special paper, special ink and other past technology advancements for verification of document authenticity. And it was a constant race against “fraud technology”.

However, all that ended in online validation of all paper documents in any IT developed country. Finally, most paper documents have been abolished. Physical or electronic documents on hands become only secure handles/pointers to records in centralized databases.

Token anatomy

Token is an analogue of paper document issued in authority institution and to be accepted in other institution recognizing the authority.

The only way to control validity of document is expiration time and authority stamps. Some post-use checks can be implemented, but it does not prevent fraudulent document acceptance to happen. So, it does not prevent crime to happen. A typical counter-measure is to delay document processing for additional checks what is not acceptable in authentication case.

Token expiration time should be no more than 5–10 minutes to workaround logout problem.

Stamp security is ensured solely by “secure” keys & cryptography technology used. Below is a dedicated section on such “security”.

In general, much more advanced client software is required:

It has to manage prompt token renewal every N seconds.
It should avoid renewal request amplification due to multiple running instances (e.g. open browser tabs).
Avoid unneeded token refresh in idle.
Has to deal with refresh failures and “harmful” for processing user actions.

What about well-known X.509 PKI then?

X.509 public key infrastructure can be seen as a “slow” and “advanced” token based authentication and vice-versa. For example, the following X.509 — JWT mapping is quite obvious:

Certificate — Token,
Certification Authority (key) — signing and/or encrypting Key,
Common Name — Subject,
Issuer — as is,
Expiration Time & Not Before — as is,
Serial Number — JWT ID,
Purpose — Audience,
Standardized Extensions — Public Claims,
Custom Extensions — Private Claims.

Basically, X.509 PKI has the same known problems:

CA private key security problem.
Problem of compromised certificate invalidation.
General weak cryptography problems.

The following sub-technologies exist as a proof of X.509 shifting towards online validation:

OCSP as generic online validation: RFC 6960: X.509 Internet PKI — Online Certificate Status Protocol, also on Wikipedia
DNS CAA record: RFC 6844: DNS Certification Authority Authorization (CAA) Resource Record, also on Wikipedia

Most likely, the related working group will come with some sort of online JWT/JWS validation as well. It’s only a matter of time.

How secure the tokens are?

You can find many theoretical claims on security of one or another cryptography technology. Let’s avoid theoretical speculations about the time when well-known attacks appear for HMAC/SHA-256, elliptic keys, AES-GCM or other types used in JWT/JWS. It’s just enough to keep in mind that widely used in the past RSA keys below 1024-bit, MD5 and SHA-1 hash functions are known to be weak now. By fact, it takes years to upgrade technology in field. There is also a rich history of token-based authentication and similar “encrypted cookie” epic vulnerability cases.

There are more serious problems in key management — incompetent and irresponsible personnel. It’s a type of security flaw when personnel does not need to be involved in crime, but unconsciously allows it to happen.

That’s fatal with symmetric keys. Use of asymmetric keys can improve the situation if third-party authentication provider with proper security practices is used. Implementation of proper automatic key rotation can be a good counter-measure as well.

However, another problem appears in poor security-related design & coding of client and protected service implementations.

What is the proper solution then?

The statement below refer to Single Sign On (SSO) complexity. For a standalone service, it’s more simple.

There must be a direct Service to AuthProvider communication channel.
Claims should be signed and the signature must be verified before further processing to prevent DoS attacks penetrating into backend infrastructure.
All claims must be verified online.
Result caching must be aware of session specifics with proper invalidation driven by AuthProvider.
Client fingerprints association is essential for token hijacking prevention.

There is no performance or scalability barriers, if hands and head are in the right place.

Conclusion

So, what is JWT and related technologies? It’s just a transport container for claims. It’s not a complete authentication solution. Online JWT/JWS validation protocol is essential.

So, what is “stateless session”? Either unintelligent wordplay or simple idiocy. Leaving choice for authors from zero security company.

So, what is “stateless” Token Based Authentication?

It’s a regression and replication of past authentication model mistakes.
It’s an aid for attackers as they need to concentrate only on token forgery as the only barrier for total control.
It’s just another recurring hype for thoughtless masses.

The alternative is scalable and implementable “stateful” sessions as the only way to go for high security cases.

There are always many paths to achieve the same goal. The chosen path depends on competence, past experience and vision.

Originally published at futoin.tumblr.com.