Fix: OIDC users losing credentials after re-login due to non-persistent encryption keys #363
@@ -70,7 +70,43 @@ class UserCrypto {
|
||||
}
|
||||
|
|
||||
|
||||
async setupOIDCUserEncryption(userId: string): Promise<void> {
|
||||
const DEK = crypto.randomBytes(UserCrypto.DEK_LENGTH);
|
||||
const existingEncryptedDEK = await this.getEncryptedDEK(userId);
|
||||
|
||||
let DEK: Buffer;
|
||||
|
||||
if (existingEncryptedDEK) {
|
||||
// User already has a persisted DEK, retrieve it
|
||||
const systemKey = this.deriveOIDCSystemKey(userId);
|
||||
DEK = this.decryptDEK(existingEncryptedDEK, systemKey);
|
||||
systemKey.fill(0);
|
||||
} else {
|
||||
// First time setup - create and persist new DEK
|
||||
DEK = crypto.randomBytes(UserCrypto.DEK_LENGTH);
|
||||
const systemKey = this.deriveOIDCSystemKey(userId);
|
||||
|
||||
try {
|
||||
const encryptedDEK = this.encryptDEK(DEK, systemKey);
|
||||
await this.storeEncryptedDEK(userId, encryptedDEK);
|
||||
|
||||
// MITIGATION: Read back the stored DEK to ensure we use the one that won the race.
|
||||
const storedEncryptedDEK = await this.getEncryptedDEK(userId);
|
||||
if (
|
||||
storedEncryptedDEK &&
|
||||
storedEncryptedDEK.data !== encryptedDEK.data
|
||||
) {
|
||||
// We lost the race. Use the DEK from the database.
|
||||
DEK.fill(0); // Discard our generated DEK.
|
||||
DEK = this.decryptDEK(storedEncryptedDEK, systemKey);
|
||||
} else if (!storedEncryptedDEK) {
|
||||
// This is an unexpected state; the store operation should have worked.
|
||||
throw new Error(
|
||||
"Failed to store and retrieve user encryption key.",
|
||||
);
|
||||
}
|
||||
} finally {
|
||||
systemKey.fill(0);
|
||||
}
|
||||
}
|
||||
|
||||
const now = Date.now();
|
||||
this.userSessions.set(userId, {
|
||||
@@ -134,35 +170,34 @@ class UserCrypto {
|
||||
|
||||
async authenticateOIDCUser(userId: string): Promise<boolean> {
|
||||
try {
|
||||
const kekSalt = await this.getKEKSalt(userId);
|
||||
if (!kekSalt) {
|
||||
await this.setupOIDCUserEncryption(userId);
|
||||
return true;
|
||||
}
|
||||
|
||||
const systemKey = this.deriveOIDCSystemKey(userId);
|
||||
const encryptedDEK = await this.getEncryptedDEK(userId);
|
||||
|
||||
if (!encryptedDEK) {
|
||||
systemKey.fill(0);
|
||||
// First time login or missing encryption data - set up encryption
|
||||
await this.setupOIDCUserEncryption(userId);
|
||||
return true;
|
||||
}
|
||||
|
||||
// Retrieve persisted DEK
|
||||
const systemKey = this.deriveOIDCSystemKey(userId);
|
||||
const DEK = this.decryptDEK(encryptedDEK, systemKey);
|
||||
systemKey.fill(0);
|
||||
|
||||
if (!DEK || DEK.length === 0) {
|
||||
// DEK decryption failed - recreate encryption
|
||||
await this.setupOIDCUserEncryption(userId);
|
||||
return true;
|
||||
}
|
||||
|
||||
const now = Date.now();
|
||||
|
||||
// Clear any existing session
|
||||
const oldSession = this.userSessions.get(userId);
|
||||
if (oldSession) {
|
||||
oldSession.dataKey.fill(0);
|
||||
}
|
||||
|
||||
// Create new session with the persisted DEK
|
||||
this.userSessions.set(userId, {
|
||||
dataKey: Buffer.from(DEK),
|
||||
lastActivity: now,
|
||||
@@ -173,6 +208,7 @@ class UserCrypto {
|
||||
|
||||
return true;
|
||||
} catch (error) {
|
||||
// On error, set up fresh encryption
|
||||
await this.setupOIDCUserEncryption(userId);
|
||||
return true;
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user
This new implementation introduces a critical race condition and contains redundant logic.
1. Critical Race Condition (Data Loss):
If two concurrent login requests for the same new OIDC user arrive, both can enter the
elseblock to create a new DEK. ThestoreEncryptedDEKfunction performs a non-atomicselect-then-update/insert, which can cause one request's DEK to overwrite the other's in the database. If a user's session uses a DEK that is different from the one stored, any data they save will be unrecoverable on their next login. This is a critical data loss scenario.2. Redundant
kekSaltLogic:The
kekSaltis generated, stored, and checked, but it's not used for OIDC key derivation (deriveOIDCSystemKeyuses theuserIdas the salt). This adds unnecessary complexity and database writes.Suggested Fix:
The following suggestion addresses both issues:
kekSalthandling.✅ Changes Made
1. Race Condition Mitigation (Critical Fix)
Problem Identified
You're right - the original implementation had a classic check-then-act race condition. Two concurrent login requests could both generate different DEKs, and whichever stored last would win, leaving the other session with a mismatched key.
Race Condition Scenario:
Solution Implemented
Added a "write-then-read-and-verify" pattern in
setupOIDCUserEncryption():How This Prevents Data Loss: