Currently, if the database is breached, the key used to sign JWT authentication tokens is available to the attacker. This means that until it is cycled, the attacker can generate and sign login credentials with any details they like, bypassing the encryption of the retro data.
The config table's privateKey should be encrypted in the DB using the same ENCRYPTION_SECRET_KEY which is used for retro data.
Currently, if the database is breached, the key used to sign JWT authentication tokens is available to the attacker. This means that until it is cycled, the attacker can generate and sign login credentials with any details they like, bypassing the encryption of the retro data.
The config table's privateKey should be encrypted in the DB using the same
ENCRYPTION_SECRET_KEY
which is used for retro data.