The majority of organisation are using token base or cookie based session authentication, whether through OpenID or other authentication libraries.
A token can be stolen and reused till it expires! Mobile application tokens usually has an unlimited expiration time.
A token cannot be changed due to the fact that it’s encoded and password protected, which is an advantage!
However what happens if an attacker gets a hold of your token? It can expose your organisation and users information and operation!
Same with a session based authentication, the client posts the login credential to the server, server verifies the credential and creates session id which is stored in server and returned to client via set-cookie. On subsequent request the session id from the cookie is sent back to the server for authentication.
A session id taken from the cookie can also be stolen and reused till it expires!
There are solution that you can invalidate a token or session but you don’t know when your token is misuse…
There are number of ways an attacker can steal your organisation token/session id:
- Websites store their token on the local storage which can be accessed e.g adding a zero iframe with your org domains to another web page.
- Monitor local network traffic to intercept the token or session id.
- Malicious Browser add-ons.
- Access your mobile phone storage.
- Physically copy it.
To secure the above vulnerability I developed a middleware that monitors token usage and report back misusage.
Just declare a set of predefined roles and the middleware will monitor it for you and report back it’s findings, then you can decide whether you ask your user to re-authenticate.
Checkout this node package:
https://www.npmjs.com/package/@mbsoft/veritoken
The README has a simple example how to use it.
Top comments (3)
Why someone will send the auth token to 3rd party servers? No sense
You send your session id or token, if it's JWT token it can be decrypt any why... the only information you usually store is your user id, client id, user role - this info means nothing but you get a extra security layer that helps you mitigate this vulnerability
As long as we limit data stored in the token like a unique id, then even in the worst case scenario it must be fine?