Skip to content
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

Open
hakanu opened this issue May 26, 2020 · 7 comments
Open

Password protected notes #99

hakanu opened this issue May 26, 2020 · 7 comments
Projects

Comments

@hakanu
Copy link
Owner

hakanu commented May 26, 2020

  • this should work per user
  • User should be able to set a master password in settings but this setting should not be saved into localstorage. Maybe it can be written to db
  • Ask user to enter this key whenever navigated to password protected note based on server's response.
  • Upon entering the pass key, content is going to be requested again. Server will resolve the note

Decisions:

  • Should we use database for this as yet another use case for db?
  • Should we encrypt the file on disk or leave it as it is?
  • Should we remember the key entered in the session? (this sounds like a potential security leakage) I'm more on the side to enter pass key every time.
@ajunca
Copy link

ajunca commented Jun 1, 2020

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:

Should we use database for this as yet another use case for db?

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.

Should we encrypt the file on disk or leave it as it is?

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.

Should we remember the key entered in the session? (this sounds like a potential security leakage) I'm more on the side to enter pass key every time.

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).

@hakanu
Copy link
Owner Author

hakanu commented Jun 1, 2020

Thanks Albert for the input. It's one of my favorite features in Trilium actually.

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)?

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.

It would be nice to not use a database

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.

My opinion on if we should encrypt the file on disk is a YES

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.

Trilium approach on this is a good one (using some timeout session).

We can memoize the contents of the handler so that no need to ask for password.

@hakanu hakanu added this to To do in Roadmap Jun 14, 2020
@clach04
Copy link
Contributor

clach04 commented Jul 6, 2021

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.

@hakanu
Copy link
Owner Author

hakanu commented Jul 6, 2021

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:

  • storing encryption key is hard
  • sqlite is not encryptable. So attacker can open and find the key there.
  • we can depend on some online storage like firebase which is a little against pervane's philosophy.

Again any idea is welcome, feel free to send PRs to me :)

@clach04
Copy link
Contributor

clach04 commented Jul 10, 2021

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).

  • Agreed, storing encryption key is hard :)
  • You may be interested in https://pypi.org/project/pysqlcipher/ -- however you still have a key needed for that - see number 1 ;-)
  • Agreed, I do not want to use a database

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).

@clach04
Copy link
Contributor

clach04 commented Jul 11, 2021

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.

@clach04
Copy link
Contributor

clach04 commented Jul 13, 2021

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Roadmap
  
To do
Development

No branches or pull requests

3 participants