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.

  • Why would the client want to verify the token? – MechMK1 Jan 23 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 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. – MechMK1 Jan 23 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 at 14:37
  • 1
    Exactly, because a.) you can't do it anyways and b.) you can't do anything about it either. – MechMK1 Jan 23 at 14:40
0

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

| improve this answer | |
  • 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 at 18:00
  • Are there anymore risks. And should a client (app) validate the token? – RicardoDuarte Jan 23 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 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 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 at 18:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.