Encrypt your Redux store.
As of February 2, 2024, I will longer be maintaining redux-persist-transform-encrypt.
I have been supporting it as best I can these past few years, but the reality of it is I have not used redux-persist-transform-encrypt, redux-persist, or Redux since 2017.
Since I no longer use any of the technologies involved and don't have a good way of testing any potential changes, I am no longer in a position where I feel I can maintain this package to my desired standards.
Additionally, redux-persist as a project also seems dead, despite an attempted change in management.
redux-persist-transform-encrypt must be used in conjunction with redux-persist, so make sure you have that installed as well.
yarn add redux-persist-transform-encryptnpm install redux-persist-transform-encryptimport { persistReducer } from 'redux-persist';
import { encryptTransform } from 'redux-persist-transform-encrypt';
const reducer = persistReducer(
{
transforms: [
encryptTransform({
secretKey: 'my-super-secret-key',
onError: function (error) {
// Handle the error.
},
}),
],
},
baseReducer
);Asynchronous support was removed in v3.0.0, as it was never fully supported and is not able to be implemented correctly given the current constraints that redux-persist imposes on transforms. See #48 for more details.
The onError property given to the encryptTransform options is an optional
function that receives an Error object as its only parameter. This allows
custom error handling from the parent application.
The secretKey provided to encryptTransform is used as a passphrase to generate a 256-bit AES key which is then used to encrypt the Redux store.
You SHOULD NOT use a single secret key for all users of your application, as this negates any potential security benefits of encrypting the store in the first place.
You SHOULD NOT hard-code or generate your secret key anywhere on the client, as this risks exposing the key since the JavaScript source is ultimately accessible to the end-user.
If you are only interested in persisting the store over the course of a single session and then invalidating the store, consider using the user's access token or session key as the secret key.
For long-term persistence, you will want to use a unique, deterministic key that is provided by the server. For example, the server could derive a hash from the user's ID and a salt (also stored server-side) and then return that hash to the client to use to decrypt the store. Placing this key retrieval behind authentication would prevent someone from accessing the encrypted store data if they are not authenticated as the user.