0

Having spent a lot of time researching, I am unable to confirm whether my system is secure enough.

  • Users have a mobile phone and login to a central authorization server by passing their username, password and a nonce. The password both will be hashed
  • Username, password will be pre-generated and given to the user through out-of-band methods. i.e. There is no registration page, and username, password that is assigned to a user will never be compromised
  • User will receive a jwt with an expiry time of say 12 hours
  • For any post or get request, the user must add the jwt in the header as per common standards
  • The server can be trusted entirely

Now my doubts are,

  • If someone intercepts the packets being sent from the mobile, he can get the jwt token, which can be used to send requests from a hacker. What prevents the hacker from sending requests by adding jwt to his requests?
  • If the incoming and outgoing packets from the mobile is breached during the login stage, the hacker will get access to the hash of the password (and salt) and username by reading the packets. What prevents him from sending that same data at a later point to the server and obtaining a jwt of its own

I am assuming the hacker is extremely sophisticated.

One thing I thought of, is every time the user tries to login, a key exchange is initiated with the server, and is then used to exchange the password. So if this information is obtained, the hacker cannot use this to authenticate as encryption keys are ephemeral in nature.

Another easier option, is to have the server simply send a nonce, which the client will use to sign the password. This is unique to a single session, so once the user logs in, if a hacker sends that same signed password it will be rejected as the nonce on server side would have expired.

However, I am unable to protect myself in the eventuality that the jwt token is accessed by the hacker.

1
2

I presume you are using https with a reasonable key length, to access the login API and receive the JWT and sending the JWT is SSL sessions. If this is the case accessing the JWT from a packet capture of the (encrypted) SSL session is not going to be fast. Hence your JWT should have a sensible expiration time and be reissued on expiration.

If you are concerned that your payload is too sensitive for https I'd suggest using a private connection (eg. tunnel over VPN) prior to app connection. For public facing apps this isn't practical.

4
  • Lets say the payload is extremely sensitive and I am extremely paranoid. Once I get the token securely (by https or a private tunnel) and send it back every time, with a request, won't sniffing allow the hacker to obtain the token and use it? – Varun Agarwal Nov 24 '16 at 11:29
  • The token will be sent in a header which will be encrypted as part of the HTTPS request. – Tim Ebenezer Nov 24 '16 at 11:37
  • Yes, but if the session expires? I have seen several apps that just use the same token again. This will be similar to a chat app, persistent connection is always kept open. – Varun Agarwal Nov 24 '16 at 11:57
  • Hence your token should have a sensible expiration policy, and the client should request a new token on expiration. – Tim Ebenezer Nov 24 '16 at 11:58

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.