Is this really secure enough for sensitive info ?

[paulverbeke]

Hi,

I just took some time to read you codebase and some things worries me, especially because IMO that completely invalidates what is said on the home page

And even if WeExpire gets hacked, your notes cannot be accessed because once they are generated they are not stored on WeExpire

My 2 cents:

• for keeping track of access requests you store the hash of the encrypted note in DB. IMO it's not ok. Moreover the hash algo used is SHA256 and isn't enough for sensitive data. If DB is exfiltrated, notes are not very securely hashed. You should use a strong hash algo designed for sensitive data or even better store only the id of the note (id that could be stored in the QR Code). Either way you effectively are storing our notes.
• since everything is done server-side in PHP, at any step of the process (note creation, request access, read note) the server have access to the content of the note, or the encrypted note and the access code needed to decrypt it. If WeExpire gets hacked, these could be intercepted easily by editing the PHP. Your service could make use of the fragment part (#) in the url to do the decryption client-side in the browser (like a lot of encrypted item sharing services do: Firefox Send, Wormhole, etc. They include the private key in the fragment part) ? The note key part of the server could be sent to the client via a call to an API (with an unique note key per note).

Thanks for creating this service, this is a great idea. I would love to use a service like this to store the credentials to my password manager to allow my trusted contacts to access it, but the service is not secured enough for this use case. And I would guess that any information you wish to give to someone in case of emergency would often be sensitive like this.

What do you think ?

[ciccionamente]

Hi @paulverbeke,

Thank you so much for taking the time to share your feedback, and apologies for the delayed response.


• As can be verified in the codebase, emergency notes are not stored on WeExpire at the time they are generated.
• WeExpire temporarily stores a hash of the emergency note for 60 days, but only in the event of an access request. After 60 days, this hash is completely removed from the database. This process helps determine whether the owner of the emergency note has already been contacted. Consequently, this procedure both protects the emergency note from unauthorised access and secures the database (even if someone obtains the database, it only contains a few hashes, making it essentially worthless).
• While there are several secure hashing algorithms available for passwords, SHA256 is both highly secure and fast for our use case: emergency notes. Since the emergency note being hashed is a combination of multiple independent variables (and not just a single password), the likelihood of a brute-force attack or hash collision is extremely low.
• WeExpire operates server-side to verify access requests; otherwise, it wouldn’t be possible to protect the emergency notes from unauthorised access (and subsequently notify users via email). We already have several safeguards in place to prevent any "unexpected" server-side edits. The alternative solution with a unique key per note would require constantly tracking previous keys, which could potentially involve personally identifiable information (PII).
• You can also run a copy of WeExpire on your local server, giving you full control over the entire setup. If your goal is to store credentials for your password manager, I suggest printing an emergency kit via your password manager (e.g. https://support.1password.com/emergency-kit/) and using a WeExpire emergency note to inform your trusted contacts about where to find it.