Security Concern with Predictable Slugs and Offline Brute Forcing of Encrypted Content

[dillonstreator]

First off, nice work - this is a cool app! I reviewed and figured I'd share a concern that came up while I was building my similar project crypt.fyi.

The current approach for encrypting and retrieving notes introduces a potential security concern:

1. Guessable Slugs: If the slugs are predictable or easy to guess, an attacker could enumerate slugs to retrieve encrypted content.
2. Offline Brute Force Attack: Once an attacker retrieves the encrypted content, they could attempt to brute-force the decryption key locally by guessing passwords.

This could potentially expose user data if weak passwords are used, despite the encryption being performed client-side.

Suggested Improvements

To mitigate this issue, consider implementing the following changes:

1. Require Password Verification Before Sending Encrypted Content:
   • Instead of exposing the encrypted content to anyone with the slug, require the user to authenticate with their password before serving the encrypted content.
   • Use a salted hash of the password created on the client side for zero-knowledge password verification. The server should only store and work with the salted hash to ensure no raw password data or unsalted hash is ever exposed.
2. Rate Limiting:
   • Add server-side rate limiting for slug / encrypted content requests to reduce the feasibility of enumeration.

[harshsbhat]

Thanks for both of this issue and #9

I will work on it ina day or two.

[ouuan]

Another concern is that, through the encrypted notes, the length of the notes and the editing time and frequency can be leaked.

[harshsbhat]

@ouuan can you please elaborate?

[ouuan]

@ouuan can you please elaborate?

The length of the ciphertext is approximately the length of the plaintext, and the ciphertext updates when the plaintext updates.

[harshsbhat]

@ouuan yes, how would you recommend to solve this?

[ouuan]

how would you recommend to solve this?

I'm commenting on this issue, because it can be resolved by:

1. Require Password Verification Before Sending Encrypted Content

[harshsbhat]

Alright! I will make this a priority then.

Thanks for your input! @ouuan