[Feature Request] Master password functionality
Opened this issue · 3 comments
In short, all files encrypted locally with the use of a master password, with current functionality until closed. Upon re-launch, the user would be prompted again.
Use case
As someone who has a lot of private information, I'd like an extra layer of security in case my laptop were lost or stolen. This is sort of the opposite of #7, which was asking for locally visible text files.
Workaround
Run AlephNote inside of a VeraCrypt volume and then close and dismount when not in use.
Other notes
-
Note that this would only prevent attacks on the local system. There is no benefit for this capability if someone were to gain access to any enabled remote storage service (e.g. Simplenote).
-
Security could be further strengthened by re-requesting the password after a configurable idle period e.g. 5 minutes or 1 hour. Other items such as weak password warnings at initial setup might also help (e.g. good = more than 7 characters, presence of special characters, upper/lowercase, etc.).
-
It is not expected that this would be a perfect security tool so please don't read this as a host of new requirements. The main goal is to foil unsophisticated attackers. Anything beyond that would probably require VeraCrypt as mentioned above.
-
#70 would also resolve this issue. It is related, but is more about collaboration with other services and operating systems that can't use AlephNote but can use compatible encryption. It would be fundamentally more secure by encrypting both local and remote storage, but is also more difficult to implement.
Well it's been a while this has been requested and sadly such vital feature is not implemented, can't believe it..!! Please do it~!
We can have a public key as "username" and a private key as "user password". This process is the same as nostr and is interesting if you want to save the login on an external device for AlephNote login. But there are login ways or login alternatives like open-id, touch-id or oauth2 which are also interesting
There are definitely two parts in this whole thing, first encrypting the notes locally and encrypting them on the remote/server site.
I think you don't even need to get that complex, simply AES encrypt all note content with the user password before syncing and decrypt them when receiving them from the server (perhaps add a defined header text to identify encrypted notes and version the used encryption algorithm/settings).
The same is the true for the local storage, here we already have a structured data format and can simply encrypt them and set an encryption_version="1" attribute or something similar.
With local encryption the user would then probably need to insert his pw on program startup (?), we can't really use the stored remote password, otherwise the encrypted notes lay directly beside their encryption key :D
Due to the whole StandardNotes API debacle I'm not as actively developing here as I did previously, but if you want to create a PR I would be happy to look over it and eventually merge it.
I guess I would recommend to do this in two parts/PR's, because the local-encryption and the encrypted-on-remote part are pretty different and someone can perhaps only want one of them enabled.