-
-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Password protected notes #99
Comments
This is an important part preventing me switching from Trilium to Pervane. I have some notes that need more protection than average (ex: notes with passwords inside, personal diary, etc). By no means I want to put pressure, but It is known what is the state of this issue? Any previsions on implementation (short, mid, long term)? My opinion on the decisions:
It would be nice to not use a database. If everything is only filesystem related it became much more robust and future proof (switching to other applications, importing/exporting, synchronization, updating, etc.) at the cost of some performance loss. If not we are falling in the same pitfall as Trilium.
My opinion on if we should encrypt the file on disk is a YES. No point on having protected notes only on the app and not on the filesystem (local or remote). I know we could encrypt the filesystem/folder (but then all notes get encrypted) or maybe have two separated folder (one for regular notes not encrypted and one folder encrypted for protected notes) but it is a lot of maintenance work for the end user and if we use multiple devices this is becoming a big mess. Also I think it should use an standard form of file encryption as we should be able to decrypt notes without Pervane.
Same as you. I'm more on the side to enter pass key every time (we minimize security leakage). I think Trilium approach on this is a good one (using some timeout session). |
Thanks Albert for the input. It's one of my favorite features in Trilium actually.
Not sure. I'm pretty busy these days. I should put solid a couple of hours to do this. Not that hard as implementation but it's hard to decide on the details of implementation. Thanks for replying my concerns.
Should we take the encryption key as flag? This is one of the hardest part in apps. Where to store the key? Flag may be a reasonable choice. So that we don't need to write it anywhere which may cause a leakage.
This comes back with a drawback of not being able to modify the files in other tools like notepad vscode, gedit etc. It'll be a pervane-specific file. Kinda locking in to the environment. But you can decrypt with the key anyways externally.
We can memoize the contents of the handler so that no need to ask for password. |
I'm interested in this. I'd be interested in a plugable encryption mechanism. I use Tombo (and derivatives), they use an algorithm which is NOT recommended today (uses Blowfish and (modified) ECB) so not something I'd recommend Pervane support but its something I'd like to implement support for. I want backwards compat as well as support on my Android phone. Links for reference:
I'm definitely NOT interested in a database. What I like about Pervane so far is that its regular files that work with my existing tools. However plugins might give some options for people who want to implement that. https://github.com/pbek/QOwnNotes/blob/develop/docs/scripting/examples/encryption-pgp.qml (which I only discovered today from the Pervane readme) has an interesting idea for user supported plugins (I'm not sure Pervane needs that). I have some ideas on options but I noticed Pervane has an indirect dependency on the cryptography package which has a safe/sane, easy to use implementation for encryption https://cryptography.io/ (as well as primitives) so that may be a good default. @hakanu is there a branch with any experimental code can look at before I start looking into this? I need to extract the crypto code out of one of my Python Tombo projects to make it a standalone module first so it maybe a few days before I get to this. RE password memoize - Tombo (and one of my projects) uses a configurable inactivity timer for how long to remember the password before re-prompting. |
Thanks @clach04 for bringing this up. I want to have plugins too TBH but the architecture is hard. Any idea/recommendation/code donation is welcome. I've recently had a baby so I can not dedicate much of a focused time to the project. With that being said, we should store the user secret somewhere and I guess this will alongside with the user login info in the db. There are many things to consider:
Again any idea is welcome, feel free to send PRs to me :) |
Congratulations @hakanu on your 👶 ! Expect some PRs and bug reports from me :). Some of the bug reports I'm likely to need help on though (for example #152).
I'm assuming based on the use case and discussion so far we're thinking symmetric encryption. I strongly discourage you from storing decryption keys on the same machine as the encrypted data. If this is encryption keys for asymmetrical then that's a different use case, but we still have the question of where does the decryption key come from? I believe prompting the browser (when needed) is more appropriate (it can be sent securely to the server from the browser, either relying on TLS or asymmetric encryption implemented in the js code on the client with a key sent by the server). The server uses sessions and it is long-running (rather than a CGI process that needs new context for each request) so it's possible to cache the password in memory on the server (if an attacker has access to memory then they have access to more than just the password). A timer could be used to forget the password after inactivity. I'll knock up a prototype with a hack to pick up the password from the environment (rather than the user, so as to focus on the server code) as a demo rather than a recommendation for production. That could also be used for key-in-database (which is not something I'd want to use). |
Proof of concept at https://github.com/clach04/pervane/tree/tombo_encryption - probably not ready for review (there is some refactoring I'd like to do), its has the general shape but none of the UX pieces. |
Decisions:
The text was updated successfully, but these errors were encountered: