jwt symmetric signature security risks (from client side)

Question

I am currently implementing an iOS app, which integrates with a cloud hosted .net backend system in azure, which.

The api login endpoint takes user/pass -> replies with an signed only HS256 jwt token. All further calls to the endpoint require an Authorization header of type bearer, and the endpoint supports renewal of this token, as long the token is not expired, for what it seems to be an infinite amount of time. (which in itself isn't great). The server-side seems to validate the signature of this token in every request.

In the past having used only RSA tokens, we always shared with clients the public key so they could verify the signature of the token. However since this api only supports HS256, this is not possible.

What security risks would a client not verifying the signature incur for the client side? An obvious one is accessing cached data within the screens. But would there be more serious ones? Thanks in advance.

Answer 1

A session token of any kind, JWT included, is expected to be an opaque blob to the client. This is actually enforced for most tokens stored in cookies, where the HttpOnly flag means the client can't inspect the cookie. Even for bearer tokens, though, there's no need to inspect the token client-side.

Indeed, I'd be suspicious of any system where any element of its security depended on the client validating the session token. Client-side validation can be useful for convenience or for offloading some performance (for example, the client might notice a token is about to expire and refresh it), but the server always must perform its own validation and make no expectation of the validity of the client data (in that example, the server needs to operate correctly if the client doesn't refresh in time, refreshes constantly, sends an invalid refresh token, etc.).

I'm not entirely sure what you mean by "accessing cached data within the screens", but it doesn't sound like a relevant problem at all. If the app wants to know how long sessions last (so it can clear its cache when they end), that's a reasonable thing to desire, but there's no need or reason for it to verify the token for this purpose; if the attacker can modify the token they can (almost certainly) also just access the cache directly.

Assuming the token is only ever transmitted over secure connections and not stored when an untrusted user/app can access it (which... if either aren't true you have other, very large problems, but none due to the risk of the token being invalid), and that the token isn't being used as anything other than "a token" (i.e. it's not also an key for client-side data encryption or some such), there's really no need for the client to know anything about the token at all.

---

The reason people use asymmetric signatures in JWTs is so that only one service can mint them, but others - which the minter might not trust - can verify them. The client/bearer is not generally a "service" in this sense. The reason people use keyed hashes in JWTs is because asymmetric crypto is very computationally expensive, especially if you want the same degree of security. The ability for the client to make heads or tails of the signature is never, in my experience, relevant (even with asymmetric signatures I've never seen a case like you talk about, where the service actually publishes the public key to the client; it's just not relevant).

Answer 2

First of all I am extremely sorry if I did not understood the question correctly.

IMHO, if a token got hijacked (implementing MiTM), then the malicious user (especially if signature is not verified and the TTL of token is infinite) can use it to impersonate as server, pushing and update (depends on how you actually built your service) and doing anything he can by impersonating server responses. Or he can impersonate the client, and try to update account details in application.

Regarding the difficulty of such attack, it requires to be targeted (because hacker have to listen to traffic first), and depends much on a server side\client side settings (storing token in server side cookies not accessible by javascript to defend against physical access, setting TTL to a very short time, and so on).