Note always deleted when "Delete after reading"

[adoyle-h]

Describe the bug

Create a note with "Delete after reading" checked. If user open the note with incorrect password. The note will be deleted.

What happened?

The note should not be deleted if user entered an incorrect password.

System information

Chrome 130.0.6723.70

Where did you encounter the bug?

Public app (enclosed.cc)

[CorentinTh]

Hi @adoyle-h
That's a good point, not easy to fix though regarding the current architecture. Note that the user can try other passwords as long as they do no refresh or close the page.

Currently, the encrypted note payload is required to check if the password is correct or not.
But the server delete the note after the first read of the payload, so the payload is not available anymore.

Here is the flow

1. User A create a note with Delete after reading and a password
2. User B open the note
   a. The client see the note is Deleted after reading from the url metadata
   b. The client ask server if the note exist (that the note is not already deleted)
   c. The client warn the user that the note will be deleted after reading
   d. The client fetch the note payload from the server + the server delete the note
   e. The client prompt the user for the password and try to decrypt the note

The lock here is that the payload is needed to check the password, but the payload is deleted after the first read.

Some options:

• Option 1 : could be to store the payload in the client side storage (localStorage or sessionStorage) and delete it after the first read. But it's not secure at all, prone to XSS attacks and require strong expiration policy.
• Option 2 : don't delete the note after the first read, but after the first decryption. The client will have to tell the server that the note is decrypted and must be deleted. But it's not secure at all since one could make a script or 3rd party client that no longer tell the server that the note is decrypted and can be deleted.
• Option 3 : warn the user on password prompt to not refresh the page or close the tab. But it's not really user friendly.

I'm not sure what to think about this, I'll think about it to see if there is a better solution.
Thus I'm open to any suggestions or ideas on how to handle this.

[ilyakonovalenko]

Hello,

It seems the quick fix is Option 2. Another way is to create another endpoint to receive payload only after password validation. So: client checks if the password is set -> client asks for the password (if set) -> client sends the password to the server for validation -> client requests payload and decrypts the content with the same password (if valid).

[CorentinTh]

Hi @ilyakonovalenko

Thanks for the suggestion!
Option 2 is a straightforward fix, but as mentioned, it's inherently less secure because it relies on the client reporting the decryption success. This introduces the risk of someone bypassing the deletion trigger, leading to unintended persistence of sensitive data

Regarding the proposed endpoint to validate the password server-side, this approach unfortunately compromises the zero-knowledge architecture we’re aiming for. In our setup, the server should never see or process the password, as that would undermine the end-to-end encryption guarantee. The password needs to stay on the client side

[ilyakonovalenko]

Then it seems there are only two ways for now:

1. Implement option 2 as it is with note author notification, so that author is aware of possible security issues.
2. Disable an ability to delete after reading in case some password is set. Non user-friendly, but would make the system most secured for now.

[TheSupremeGod]

Maybe the decryption handshake could be extended using a second encrypted payload(for which the server knows the plaintext content) with the same key. It would look like this:

1. Client gets info about the deletion tag being set
2. Client asks for dummy payload and tries to decrypt it using the password
3. If correct either:
   a. Send the plaintext back to the server, proving it has the correct password
   b. Server sends the plaintext to the client and the client decides if the password was correct
4. Server sends real payload
5. Client decrypts real payload using the same password

Advantages:

• Server never sees password
• Client can't see contents without the deletion occurring

Disadvantages:

• If 3a is used, the server will know that decryption was successful and if a note is deleted, it proves that the note was decrypted successfully (not sure if relevant)
• If 3b is used, the client still controls the deletion. It can lie to the server and force the note to be deleted (which already happens)