0

I'm trying to create a mobile app which helps to connect with my mobile app. While going through authentication I used JWT. While authenticating it, it returns access token and refresh token to the client but if both of them are sniffed so there can be a concept of account takeover. Though I'm using HTTPS the attacker might get the access token by intercepting the request with burp suite.

But the Access token is also passed through header in request. Is there any way to secure my access token before sending a request?

Improve this question

1 Answer 1

Reset to default
2

Though I'm using HTTPS the attacker might get the access token by intercepting the request with burp suite

This means that the attacker has a certificate trusted by the client. HTTPS does not protect against MITM by a trusted party, which in case of Burp suite is often the client themselves (i.e. reverse engineering the app).

Such MITM could do anything in the name of the user anyway, by modifying any requests passing through or injecting script into the responses. There is no need to explicitly know the access token for this, i.e. protecting the access token would not help here anyway.

That said, the access token is basically an authentication method which relies on sending the secret to the server, similar to a password. There are authentication methods which only prove the knowledge of a shared secret without sending the secret itself, like Digest authentication. There are also methods which rely on asymmetric cryptography to prove knowledge of the private key, like client certificates or signing some server provided challenge. In these cases the secret itself is never transmitted. But it will still not protect against attacks by the client itself using Burp suite or similar, because the client might extract the necessary secrets from the client app.

Improve this answer
3
  • Then how can I prevent such things from the attackers?
    – swamper
    Feb 10, 2022 at 7:34
  • 1
    @swamper: You cannot prevent attacks from an attacker which is fully trusted by the client (which might be the client itself). If you want to prevent clients to reverse engineer your app or similar - this is not possible as long the the client has full control of its own system. In case of an untrusted attacker - here HTTPS already prevents the attacker to sniff the access token.
    – Steffen Ullrich
    Feb 10, 2022 at 7:48
  • Something you didn’t mention @SteffenUllrich… the HTTPS connection could be configured to only allow a pinned certificate or key. Limiting the set of trusted parties. (Not a full defence… but it does make it harder to interfere)
    – LvB
    Feb 10, 2022 at 9:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .