3

I'm working on a legacy application that issues JWTs with a short expiry time.

They do not have refresh token functionality implemented.

So obviously while using refresh tokens would be the right solution, for the sake of argument assume that's not going to happen.

It occurs to me that 'Hey I could just store the username and password locally and just re authenticate when the user gets kicked out'.

This question:

How dangerous is storing the hashed password in local storage?

Suggests that localstorage would be a bad idea, and that access tokens should be stored in cookies instead. So sure, I could put the username and password into a cookie.

What's the security issue with doing this?

dwjohnston
  • 707
  • 5
  • 20

1 Answers1

4

The main problems are:

  • The username and the password are sent again on every request, making it easier to steal the actual credentials instead of hijacking the session. A compromised session can easily be revoked by removing the access token, but a compromised login requires locking the account and changing the password. Cookies could be stolen...

    • in man-in-the-middle (MITM) attacks
    • in Cross-Site Scripting (XSS) attacks
    • from a local, unencrypted store.

  • It's impossible to efficiently expire a session server side: this relies on trust that a client forgets about the cookie when it is set to expire. This makes e.g. using shared computers a lot more riskier than using session tokens.

  • Unless the password is weakly hashed (or stored in plain text), checking it over and over again on every request is total waste of resources.

Similar authentication schemes exists and are even widely used, as for example HTTP Basic authentication (RFC 7617, 2) works like that. If it's absolutely necessary to use such authentication, these problems must be at least mitigated with proper encryption – likely HTTPS enforced with HTTP Strict Transport Security HSTS (RFC 6797).

Community
  • 1
Esa Jokinen
  • 16,100
  • 5
  • 50
  • 55