0

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.

RicardoDuarte
  • 105
  • 2
  • Why would the client want to verify the token? –  Jan 23 '20 at 14:29
  • Its an HR application, where users will send potentially confidencial information from the client (project related information, or even personal) isnt it best practice to do so? verifying the token would allow to know if a token was tampered with would know not send information back to the server? No? – RicardoDuarte Jan 23 '20 at 14:34
  • What would be the point of using a tampered token? The original web server would not be able to use it and nothing would work. –  Jan 23 '20 at 14:36
  • Yes that is correct. So from ur perspective there is no point in validating the token from the server? – RicardoDuarte Jan 23 '20 at 14:37
  • 1
    Exactly, because a.) you can't do it anyways and b.) you can't do anything about it either. –  Jan 23 '20 at 14:40
  • I know i cant do it with HS256, but the backend developers are willing to change it to RSA, if there is case for it. I was just trying to understand if i was missing something. Probably i worded the question wrong. And if there is a valid case to do it, and what gains/losses would exist if the app verifies its signature. – RicardoDuarte Jan 23 '20 at 14:56
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/103614/discussion-between-ricardoduarte-and-mechmk1). – RicardoDuarte Jan 23 '20 at 15:06

2 Answers2

1

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).

Rashad Novruzov
  • 658
  • 2
  • 13
  • The token can be renewed through a renew endpoint and retrieves a new token each time, but the session will be alive as long Its renewed. Server side developers are happy to change the alg to rsa, so i can sign it as long there are security risks to the app not verifying its signature. Serverside developers say in each request they will validate the token signature, to make sure it wasnt tampered. From what i can think of, leaving it as it is would allow a user to do mitm and seeing cached screens which can have personal information (depending at which point the user is), is there anymore? – RicardoDuarte Jan 23 '20 at 18:00
  • Are there anymore risks. And should a client (app) validate the token? – RicardoDuarte Jan 23 '20 at 18:01
  • RicardoDuarte, I am sorry for not being clear enough. Reading your question, I understood that token's life are set to infinite. My answers were regarding security in replay attacks, not tamper ones. Forgive me if I misread something. – Rashad Novruzov Jan 23 '20 at 18:06
  • 1
    Regarding client side verification - it does not give much, since when MiTM attack will be involved, the attacker can route token validation requests to himself, and validate them. If I wanted to defend client from that vector, I would have implemented an encrypted tokens. – Rashad Novruzov Jan 23 '20 at 18:14
  • Thank you rashad, i think both ur answers and google have given me a enough information to take onboard. I was aware of what you @mechmk1 suggestions but i was worried i was missing something. – RicardoDuarte Jan 23 '20 at 18:16
  • Happy to help RicardoDuarte, happy coding! – Rashad Novruzov Jan 23 '20 at 18:17
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).

CBHacking
  • 40,303
  • 3
  • 74
  • 98