I have noticed that the password for the synchronization target can be read in plain text in the database.sqlite file (Windows-Client). Also the texts in this file (which should be encrypted) are readable in plain text.
Is there a solution or is a troubleshooting planned for the near future?
1 Like
Also the texts in this file (which should be encrypted)
Please have a look at the doc as it's not what end-to-end encryption does - https://joplin.cozic.net/e2ee/
2 Likes
Just started using Joplin and I notice that the E2E and the WEBDAV passwords are stored in plaintext inside the settings table of the SQLite Database on the Windows version. I presume the same on Android.
I get that this is not what E2E is for and - personally I am synching this to my own NAS using WebDav so not worried about E2E but not too pleased that the credentials are in plain text. Do you have plans to resolve this either using an encrypted database format or just encrypting these specific values.
I realise whatever you do the encryption must be two way so a hash is not suitable but my concern is not making this bulletproof but preventing casual viewers reading the contents.
2 Likes
I think this issue has been explained a thousand times in the forum and on github. If your system is compromised, everything else goes to !@#$ anyway, so what’s the point?
Inclined to agree with @tessus here. As you’ve noted, it would only prevent casual viewers from glancing at the password, but if someone is in your system manually digging around in your Joplin profile database, I somehow doubt it’s still a casual viewer.
(Don’t get me wrong, I wouldn’t be against having additional encryption; I just don’t see this as such a pressing issue.)
1 Like
It is common best practise to not have passwords in plain text!
If my system is compromised then I don’t want my NAS compromised too. Personally I have now having seen this created a dedicated user/password in a separate area of my NAS just for Joplin.
Encrypting the database would be an obvious solution to this but is overkill from my perspective.
I do not keep my passwords in a notepad file on my PC! That would be crazy - what’s the difference!
I presume on Android and iOS you have device level encryption and sandboxing - not the same on Windows.
5 Likes
I agree that plain text passwords are almost never a good idea. However in this case, I also agree with @zblesk that this issue is not a pressing one.
Security is a highly complex topic and it cannot be reduced to a single item. e.g. people are supposed to use device or application passwords (tokens) instead of passwords. Should there be a problem one can always revoke that token.
Full disk encryption is another important part.
In any case, if someone has physical access to your machine it’s over in 99% of all cases anyway. The same is true, if someone has access to the hypervisor of virtualized servers. The adversary only has to dump the VMs memory and search for passwords in the dump (even for the passwords of the full disk encryption for that VM).
1 Like
I just noticed this too in the electron app. I really think a form of encryption should be implented. It is bad practice and I have very mixed feelings about this. I realize this is open source but not storing plaintext password are security basics.
I just started to use Joplin and I’m so happy that I finally have found, the app which does exactly what I need and a little bit more.
However, it is my huge concern that Joplin keeps my Nextcloud password as plaintext in the database. At least for Linux client, it can use KDE-wallet or GNOME password system(s) to avoid this security problem.
I can ( unfortunately just a bit ) reduce this vulnerability
- As @egooner suggested - create another Nextcloud account, with strong restrictions, for Joplin
- Move ~/.config/joplin-desktop to the encrypted folder and create a soft-link back to ~/.config
Please consider the utilization of desktop encrypted password systems to keep our data storages safe.
1 Like
Yes ideally the password should be saved in the system keychain. It shouldn’t be too hard to do using node-keytar https://github.com/atom/node-keytar
The portable app version thought would still need to have its password in the database.
1 Like
The portable app version thought would still need to have its password in the database.
I don't know about android, but iOS definitely has builtin password keychain. Pretty sure there is a lib, which works with iOS too.
Let's make Joplin ideal 
1 Like
I’ve replaced Evernote with Joplin about a year ago. Joplin is the perfect solution for me but I’m surprised security is taken so lightly.
OK this is an open source solution (I assume with a few developers working on their own time) and security is indeed a complex topic, but I can never agree with @tessus saying this is not a pressing issue.
@egooner explained it perfectly, security should be considered at every step. Even with a computer compromised there is no reason to ease the path for an attacker to enter other systems. As he perfectly said nobody in their right mind would save their passwords in clear text on their computer.
Generally speaking an option to secure Joplin app on startup (with a password for instance) would be nice. The password itself could be used to encrypt these app necessary data.
As far as I’m concerned Joplin could be of great interest even to enterprises, but it can never be considered by an IT professional with such an open door. Obviously just my 2 cents as I have faith in Joplin and I believe it deserves wider adoption.
Anyway, I thank you for this wonderful tool, I host my own nextcloud and Joplin perfectly complements my setup.
1 Like
Security is not taken lightly at all. You probably haven't read the countless posts I wrote in other topics and in the gh issues.
There are many tools available to do what you want. If you want local encryption go with VeraCrypt or other container based encryption tools. Most OS even have their own. macOS has encrypted (sparse) images, Linux has cryptsetup/LUKS/...
Most people also use FDE - or at least I hope so.
All I am saying is that adding this to Joplin, when there are so many options available, is a disproportionate use of time that can be used somewhere else.
4 Likes
I disagree. I think the problem is having ANY encryption. It just confuses people. As far as access to the computer is concerned, someone could break in and steal the computer. Anything I want protected, and I have LOTS of stuff that needs to be protected. I remote into law offices and accounting firms and have total access to them. I have many clients email passwords etc. I have credit card information etc. stored on my computer. All that is properly encrypted, mostly in Keepass.
I don’t store sensitive stuff in Joplin. It isn’t a password safe. It isn’t tested and validated for security. They made the decision to offer encryption while stored on servers for syncing, but I still wouldn’t store any of the information that needs to be secure in it.
This is not a criticism of Joplin. I use it every day and have thousands of notes. I love it. I also love Keepass. I don’t clip websites or notes on how to fix a Quickbooks problem in Keepass, or passwords in Joplin.
1 Like
Well I guess that the E2E encryption password isn’t so much of an issue considering that all the notes are accessible and readable in the database in clear anyway.
I perfectly understand that E2E encryption is made to sync notes while avoiding eavesdropping, not to provide security in Joplin (pity though).
Nextcloud’s WebDAV password (in my case) is definitely more of an issue as it opens a door to another system (not just Joplin). If you store access to another system you’re expected to be responsible to do that securely. If your answer to this is don’t use remote sync, well why use Joplin then.
It’s kind of fun to be able to have a peek in DB and sometimes it solves some issues. But security is only as good as its weakest link and from this standpoint Joplin is a weak link.
I use all the tools and protections you mentioned for what they’re made, make it keepass or lucks whatever. Still I would expect a note taking app (every app actually) to be secured enough.
I store a lot of notes (probably like everybody else) definitely not ultra secret or worthy of an attack (also probably like everybody else) but maybe things I wouldn’t want to end up in the wrong hands anyway.
You can’t just rely on other systems to do the job. Ok your hdd should be encrypted fine. You forget to lock you computer once while going to the bathroom (shit happens), boom it’s one protection done and Joplin is « naked ». So yes I expect security at each level and at some point this is not the problem of « another layer », it’s every piece of software’s problem. Security is only as good as its weakest link.
It’s like protecting a house with a security system. A house is never secure but thieves statistically spend just a few minutes onsite. The purpose of protection is to make things difficult enough that they’d better go away. It’s the same here. It is about making an attacker’s job just painful enough. I know someone with motivation can crack anything it’s not the point. They just won’t take the time unless they know they’ll get some valuable data, which is not the case for most people so why bother.
I won’t stop to use Joplin because it’s too good a software and at least I’m aware of this limit and I understand what the E2E encryption is for. But I assume many people believe Joplin is secure because the way E2E encryption is presented gives them a false sense of security.
For me security is not a low priority feature. Joplin provides plenty already and I love it. I wouldn’t expect it to be Fort Knox, but at least to do it’s part to protect my data without having to rely on tricks (I read someone stores the joplin-desktop in a vault and has created a link from the vault to it’s original location, nice trick but not user friendly).
I don’t believe we’ll ever agree on that, but the way I see it it’s a profond limitation for a wider adoption of Joplin and certainly an issue for most of the people who wrongly believe Joplin is secure.
1 Like
To be fair If you want to solve the local encryption issue this has been covered a few times and this post Change .sqlite location on MacOS? On encrypted drive? covers the trick I mentioned. Then your Joplin is « hardened » enough for the use case we’re talking about. But it’s a step you need to take on your own.
You can use tokens in Nextcloud (app password), which can be revoked. But in either case, I hope you change passwords as soon as your system is compromised.
E2EE is more than just transport security, because E2EE over an unecrypted channel still reveals the credentials for the sync target. E2EE ensures that the data cannot be read on the sync target.
However, E2EE does not necessarily mean encrypted data at rest on your local machine/device. That's another story. Take Signal or WhatsApp which both provide E2EE (although I'm a bit fuzzy about WhatsApp), but the data is still available for someone who has access to your device.
I certainly do undertand that people want LOCAL data encryption, but that's not the job of Joplin. Joplin makes sure that the data is safe on a public cloud.
Security aware people don't share their device. If they do, they use encryption based on the user. Thus a user can't access data of another user. (I'm not talikng about user/group security on the filesystem). This is readily available in most OS.
So, if one decides to use http to transfer encrypted data (which revelas the cloud's credentials, but not the data) or shares a device (which could make personal data available), it's their fault. It's the same thing when you share your computer, but didn't log out of your online banking. Will you argue that it's the bank's fault?
That being said, there's a ticket open to store the cloud credentials in the OS's secure key-store.
Security is not only the responsibilty of an application but the entire eco-system. Do you think your data is safe, if you used a cloud provider (droplet, VM, ...) and full disk encryption? It is not. Someone with access to the hyper-visor can create a snapshot which includes the RAM, which can then be used to retrieve the password for the FDE. The use of security chips in hardware is a step in the right direction, but it's still not fully established and even in those cases there could be ways to circumvent it.
2 Likes
hello Tessus,
I use own WebDav Server and I will not that the APP store my access data somewhere else!!!
Is it possible , that you remove in the next version of the APP the access data from the LOGS!
+you wrote:
Linux has cryptsetup/LUKS/…
LUKS and disk encryption saves your data only when the system offline, what about running systems?
I'm not agree with You!
You put the log.file on FS with permission 644 and user:user
so each application running on the system (under this user and under others) have access to this log file! So I can very easy access to this file also from the Browser, from JS for example.
I don't understand You resisted. Nobody from customers will have password in the LOG file. Why will You do it? It's simple to fix it and everybody are happy!!!!
1 Like
The app now stores the password in the keychain on macOS and Windows. It doesn’t work on Linux yet, but help is welcome…
3 Likes