[PB-4737] feat(user): add public keys validation for account recovery #851

douglas-xt · 2026-01-07T17:54:51Z

This PR adds validation of public keys during account recovery to prevent users from restoring their account using a backup file that doesn't belong to them.

When a user performs account recovery, the public keys included in the backup file are now compared against the keys stored in the database. If the keys don't match, the recovery is rejected with a clear error message indicating the backup file doesn't correspond to the account.

This change works in conjunction with updates in the SDK and drive-web that now include public keys in the backup file generation and send them during the recovery request.

sg-gs · 2026-01-08T09:00:31Z

src/modules/user/dto/recover-account.dto.ts

+  @ApiProperty()
+  @IsOptional()
+  kyber?: string;
+}


Add a line between this class and the next one

Why in this class ecc and kyber are optional? Isn't it enough just to have optional public keys field in RecoverAccountDto? Because now we can have {ecc: undefined, kyber: underfined}, {ecc: , kyber: underfined}, {ecc: undefined, kyber: } and I don't think we should accept those as valid input

sg-gs · 2026-01-08T09:01:53Z

src/modules/user/user.usecase.ts

    }

+    if (!withReset && !publicKeys) {
+      throw new BadRequestException('Invalid backup file');


'Invalid keys' it's a better naming as you do not know if those come from a backup file or anything else in the future

sg-gs · 2026-01-08T09:03:01Z

src/modules/user/user.usecase.ts

+        publicKeys.kyber && existingKeys.kyber !== publicKeys.kyber;
+
+      if (eccMismatch || kyberMismatch) {
+        throw new BadRequestException('Invalid backup file');


Same here. In this case it could be worth it to specify which key is failing.

sg-gs · 2026-01-08T09:05:29Z

WDYT of this PR @TamaraFinogina ?

TamaraFinogina · 2026-01-08T11:38:52Z

src/modules/user/user.usecase.ts

+
    const user = await this.userRepository.findByUuid(userUuid);

+    if (publicKeys) {


if withReset = true and mismatching public keys, then backup won't go through?

@sg-gs Do we require/can send publicKeys for account reset? Becuase now we check public keys and if they fail we abort even if it's withReset=true

@TamaraFinogina @douglas-xt no, when account is being reset its because they have no backup file in the first place

so yeah, looking closer to the flow it would go through. withReset = true, no backup file so publicKeys are undefined and this doesn't execute.

@jzunigax2 Ok, thanks! I would really prefer this function to be more explicit, so that the key reset only happens when the account is reset, and public keys are checked only when it's a backup. But it's ok

agreed it's kinda hard to read, @douglas-xt could you refactor this a bit? maybe simply moving the if withReset check to the top of the function and doing an early return would do the trick? otherwise all else looks good to me

TamaraFinogina · 2026-01-08T11:48:27Z

src/modules/user/user.usecase.ts


+    if (publicKeys) {
+      const existingKeys = await this.keyServerUseCases.getPublicKeys(user.id);
+      const eccMismatch = publicKeys.ecc && existingKeys.ecc !== publicKeys.ecc;


If we send publicKeys = {ecc: underfined, kyber: underfined}, then publicKeys.ecc would be false, right? so, the eccMismatch will be false without even checking existingKeys.ecc !== publicKeys.ecc; part, no?

I think we shouldn't accept those keys. Or at least use something like
! publicKeys.ecc || existingKeys.ecc !== publicKeys.ecc

then undefined, null or similar keeys will give a mismatch

TamaraFinogina · 2026-01-09T08:54:26Z

src/modules/user/user.usecase.ts

+      const existingKeys = await this.keyServerUseCases.getPublicKeys(user.id);
+      const eccMismatch = publicKeys.ecc && existingKeys.ecc !== publicKeys.ecc;
+      const kyberMismatch =
+        publicKeys.kyber && existingKeys.kyber !== publicKeys.kyber;


@douglas-xt This check would pass for publicKeys = {ecc: underfined, kyber: underfined} without even checking what existingKeys are. I know that now they are not empty, but if we change that in the future this line becomes an issue. Can we remove publicKeys.kyber && and just do the comparison?

TamaraFinogina · 2026-01-26T16:29:36Z

src/modules/user/user.usecase.ts

    const { mnemonic, password, salt, privateKeys, publicKeys } =
      newCredentials;

+    const user = await this.userRepository.findByUuid(userUuid);


Other parts of the code check this after calling findByUuid

if (!user) { throw new NotFoundException('User not found'); }

or

if (!user) { throw new BadRequestException(); }

TamaraFinogina · 2026-01-26T16:34:22Z

src/modules/user/user.usecase.ts

-    if (!withReset && !shouldUpdateKeys) {
+    if (!shouldUpdateKeys) {
      throw new BadRequestException(
        'Keys are required if the account is not being reset',


@jzunigax2 @douglas-xt Do we need to check public keys too? Or do we still have both backups with/without publicKeys?

P.S. I think we also need to throw an error when privateKeys are not given at all

sonarqubecloud · 2026-01-26T17:36:41Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
87.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

douglas-xt self-assigned this Jan 7, 2026

douglas-xt requested a review from jzunigax2 as a code owner January 7, 2026 17:54

douglas-xt temporarily deployed to development January 7, 2026 17:54 — with GitHub Actions Inactive

github-actions bot added the ready-for-preview label Jan 7, 2026

douglas-xt force-pushed the fix/validate-public-keys-on-recovery branch from 4ca295d to 212af49 Compare January 7, 2026 18:06

douglas-xt temporarily deployed to development January 7, 2026 18:06 — with GitHub Actions Inactive

feat(user): add public keys validation for account recovery

c635ea3

douglas-xt force-pushed the fix/validate-public-keys-on-recovery branch from 212af49 to c635ea3 Compare January 7, 2026 18:26

douglas-xt temporarily deployed to development January 7, 2026 18:26 — with GitHub Actions Inactive

sg-gs self-requested a review January 8, 2026 08:59

sg-gs requested changes Jan 8, 2026

View reviewed changes

TamaraFinogina reviewed Jan 8, 2026

View reviewed changes

fix(user): address PR review comments for public keys validation

4880def

douglas-xt temporarily deployed to development January 8, 2026 17:30 — with GitHub Actions Inactive

douglas-xt requested review from TamaraFinogina and sg-gs January 8, 2026 17:34

TamaraFinogina reviewed Jan 9, 2026

View reviewed changes

fix(user): simplify public keys validation

b3b4406

douglas-xt temporarily deployed to development January 9, 2026 11:56 — with GitHub Actions Inactive

douglas-xt requested a review from TamaraFinogina January 9, 2026 12:05

refactor(user): separate reset and recovery flows with early return

b1d00ee

douglas-xt temporarily deployed to development January 26, 2026 16:05 — with GitHub Actions Inactive

TamaraFinogina reviewed Jan 26, 2026

View reviewed changes

fix(user): add user existence validation

1dc1729

douglas-xt temporarily deployed to development January 26, 2026 16:53 — with GitHub Actions Inactive

douglas-xt requested a review from TamaraFinogina January 26, 2026 16:57

TamaraFinogina previously approved these changes Jan 26, 2026

View reviewed changes

refactor(user): add explicit validation for missing privateKeys

125bca6

douglas-xt dismissed TamaraFinogina’s stale review via 125bca6 January 26, 2026 17:33

douglas-xt temporarily deployed to development January 26, 2026 17:33 — with GitHub Actions Inactive

douglas-xt requested a review from TamaraFinogina January 26, 2026 17:37

TamaraFinogina approved these changes Jan 26, 2026

View reviewed changes


		const user = await this.userRepository.findByUuid(userUuid);

		if (publicKeys) {

[PB-4737] feat(user): add public keys validation for account recovery #851

Are you sure you want to change the base?

[PB-4737] feat(user): add public keys validation for account recovery #851

Uh oh!

Conversation

douglas-xt commented Jan 7, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sg-gs commented Jan 8, 2026

Uh oh!

TamaraFinogina Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TamaraFinogina Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TamaraFinogina Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sonarqubecloud bot commented Jan 26, 2026

Quality Gate passed

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

TamaraFinogina Jan 8, 2026 •

edited

Loading

TamaraFinogina Jan 26, 2026 •

edited

Loading

TamaraFinogina Jan 26, 2026 •

edited

Loading