1

I've been studying front-end developing using ReactJS and back-end using ASP.NET Core and as a first step I've been developing an authentication/authorization (login) system.

I've implemented access token that expires in 1 hour and refresh tokens that expires in 7 days or when a new access token requested (in exchange for the old one and a valid refresh token).

I tried to follow people's advice and use HttpOnly cookies for the refresh token but I've struggled with that, my API would only get the same (old/expired) refresh token from the cookies... so I decided to send the refresh token and access token as json when refreshing my access token.

On the front-end I'm saving both tokens on Cookies (non-HttpOnly) using js-cookie package, BUT I'm encrypting them using AES 256-bit before saving. I've been told localStorage and Cookies (non-HttpOnly) are vulnerable to XXS attacks, but I'm wondering how vulnerable are my tokens since I encrypt them with a private key using a U.S. Federal Information Processing Standard?

Pavel Gatilov
  • 7,579
  • 1
  • 27
  • 42
asallan3
  • 43
  • 5
  • 2
    How can the front-end use them if they are encrypted? Where does the decryption happen? – Juraj Martinka Feb 01 '23 at 05:26
  • @JurajMartinka front-end encrypts and decrypts. When I receive the tokens I encrypt and save both of them to cookies. When I want to use, I get them from the cookies and decrypt. But if an attacker manage to access them from the cookies on an XSS attack for instance they'll be encrypted – asallan3 Feb 01 '23 at 11:50
  • Where is the encryption key stored if you are encrypting/decrypting on the token. It sounds like it will be easily accessible to the end user or attacker. – Juraj Martinka Feb 02 '23 at 05:04
  • @JurajMartinka its on an exported constant – asallan3 Feb 03 '23 at 12:28
  • How is it safer than storing the token in plaintext? 3rd party script could just decrypt it easily using the same method as your javascript frontend. – Juraj Martinka Feb 07 '23 at 14:01

1 Answers1

0

As juraj-martinika implied, client-side encryption with client-side stored key cannot make anything more secured. An application level, the challenge with any encryption is not the encryption process, but the key management process. Your encrypted data is as secure as your key storage is. If you store the key in a constant in JS file, or a JS variable, or local / session storage - it's as easy to get your encrypted data as if it were not encrypted at all.

There's a good topic about patterns you might use to implement secure token management: Where to store the refresh token on the Client? See what can help in your case.

If you could use cookies - I would revert to them, but solve the issue with getting outdated ones.

Pavel Gatilov
  • 7,579
  • 1
  • 27
  • 42
  • Offtopic, but for cookies - you were probably missing cookie updates at the time of refreshing. Ensure that when access token expires and a new one is issued, then your backend sends another set of Set-Cookie headers, so that cookies are updated in the browser. – Pavel Gatilov Jul 05 '23 at 15:30