Live data from Hacker News

Show HN: I made a free, ad-free and open source tool for sharing private notes

burnernote.com

21–30 of 80 posts

Re: Show HN: I made a free, ad-free and open source tool for sharing private notes

#21
post #2

Very cool, but the FAQ doesn’t address the questions people will ask: open source is fine, but what guarantee do we have that the source code matches the deployed code? Or that the deployment is done in a secure environment?

You have to implement the encryption logic client side. But then now the client has to verify the JavaScript they receive upon visiting the URL matches what is published in the open repository.

I’m not sure what convenient method exists to do this for the client. You’d have to compare hashes and idk how that could be done in a easy and trustworthy manor.

Re: Show HN: I made a free, ad-free and open source tool for sharing private notes

#25
First of all, this is a cool idea. I always love to see something private and encrypted. But I found some concerns and ideas about your project (and I think you may can fix these):

0. This has XSS vulnerability. If attacker writes down this memo: do_the_evil_things() and passes to people, they might be unknowingly attacked(get tracked by attacker their IP/Browser fingerprint, mine cryptocurrencies for attacker, etc...)

1. This basically works under server-side encryption. When user type their text in the website, it is encrypted with the secret key on your config file and saved on the database. This is only effective when attacker only succeeds to crack the database. Also, you can read the text. I know you won't, but you know, cryptographers don't trust anyone. If you want to mitigate this, you might want to learn about end-to-end encryption. In short: the hash of the private link is the secret key. The browser randomly generate the key and encrypt/decrypt the text. The server only receives/saves the ciphertext.

2. AES-256-CBC is unsafe because it provides confidentiallity and not authenticity.[1] This means the attacker who can only crack the database can edit the ciphertext to pseudo-arbitrary plaintext under certain circumstance without knowing of the key. Also under another circumstance, attacker can use 'Padding oracle attack' to recover the ciphertext. it seems your service is not in this case: Laravel's encryption is AES-256-CBC + MAC, which mitigates this problem. So this is safe, but next time, if you write some crypto-related things without Laravel, you'd better use some high-level library such as libsodium or sjcl.

3. This service uses CloudFlare. Using CloudFlare might be safe on small project because they have rock solid WAF to prevent general attacks. But it may be unsafe for a whistleblower from NSA: when it matters with state-sponsered attackers or law enforcements, CloudFlare can be attacked/warranted. Then it becomes another attack vector.

Again, your service and idea are cool. But you should remember that this area is full of land mines, dragons, and dinosaurs with laser guns.

Welcome to privacy/crypto world!

[1]: https://arxumpathsecurity.com/blog/2019/10/16/cbc-mode-is-ma...

Re: Show HN: I made a free, ad-free and open source tool for sharing private notes

#30
post #4

Earlier quoted context omitted.

> what guarantee do we have that the source code matches the deployed code? What is the answer to this question in general? Genuinely asking, I never considered this but it seems like a real concern for any OSS.

For an app that exists solely on the client it’s easy to provide a md5 hash that can be verified. This was and still is a popular solution if you torrent to make sure you’re getting what the original seeder intended. The same philosophy applies here. For back end apps it’s inherently not possible.

Please do not use md5 in 2021. At least use something like sha256.
Post reply on HN