Reputation: 6119
I'm building an Outlook Add-in (which is basically an iframe served in Microsoft Outlook client, be that Windows, Mac or browser). It's an internal company tool that sends data to our server. It uses React/JS/Node.
Our endpoints use basic authentication, so I need to pass a username/password with each request.
The problem is I would like to "remember" each user so they don't have to enter credentials every time the app loads up. I've figured I can use HTML5 localStorage
to persist username/password values.
However I'm wondering how safe this is and suggestions for how to keep a copy of the password?
Maybe do a base64 encoding of 'username:password' (for Authorization HTTP header) and store that instead?
Upvotes: 1
Views: 933
Reputation: 43196
A session key might be a good alternative. Instead of passing around the username/password pair, you can instead have the server create a session cookie to be used for authentication.
I'm not an expert on this, but here is one way I'd do it if I had to:
The client should generate two keys: A public and private key. Store these keys in sessionStorage
(not localStorage).
When the client attempts to "authenticate" with a username/password, the username, password, and secret key, should be encrypted with the server's public key and sent to the server.
The server's public key can be stored in localStorage
. Find a way to transmit this key to the client. Maybe an endpoint like /pub-token
?
The server will decrypt this username/password and after validating the pair, store the client's secret key, and generate a session cookie, which is sent back to the client.
Now in subsequent requests, the client will encrypt any message being sent to the server using it's public key and the session cookie will accompany those requests.
The server will validate the session cookie, and decrypt messages sent by the client using the client's secret key.
On the server side, you can use a fast key-value store like redis or memcached to map the session key to a client's secret key.
When the server determines the session is "over", it will delete the session cookie and the client will need to generate a new key-pair again (or keep using the same one...).
I'm not sure if this flow fits the notion of a "session key", but I find this is more secure than simply having the server generate a key and using only that key as authentication.
Upvotes: 0
Reputation: 1203
I think there's no safe way to store the password on the client side. However I have two recommendations.
Because you are using React you don't have lot's of page refreshes, you can ask for the password on each page refresh and store it as a variable (very safe).
If you want to store it, then do not use base64
encoding. Instead sign the password with jwt
on the client and store the signing secret as a config variable then uglify the config file and minify it. This will make it very hard to find the secret.
Upvotes: 1