I recently signed up for Sync and it works reasonably well. However, I noticed, that after entering my encryption password for Sync, I never had to enter it again on the same device. I assume, Obsidian stores the password somewhere (hopefully not as plain text) and I would like to know where that is and how it protects the password on my local device.
You can read about the security here: Security and privacy - Obsidian Help
Well, I did that - twice. It does not answer my question.
From a general point of view, there is no need to store the password locally. After an initial login session it’s quite normal to rather store some access token granting access between the current device and the external service. Then depending on security protocols these token might need to be refreshed/renewed every now and then, and occasionally some services would then need a new logon session.
I’m not saying this is what Obsidian does, but I’d be very surprised if they actually stored the password locally on your device instead of a similar scheme using some access token.
Thank you very much for your reply! This is exactly the kind of information I’m interested in.
Still, I would be interested in a confirmation from developer’s side that this is actually what is going on. Also, if confirmed, it would leave me with the following follow-up questions:
- Where on the local device are the access tokens stored?
The reason why I ask this is that I put my local vault as well as the Obsidian executables into a VeraCrypt container which I keep on a portable device. However, I noticed that Obsidian creates some folders under %appdata%\obsidian (Windows). While the client device I am using is a trusted device, I do not want any of the data I keep in my vault to remain on that device once I close the Obsidian app and unplug the portable device or unmount the VeraCrypt Volume. Especially not any passwords or access tokens that might grant access to the entire remote vault. - What security measures are implemented to protect the access tokens?
More specifically: Are they flagged as HttpOnly to protect agains access from JavaScript (e.g. via compromised community plugins) and as Secure to ensure they’re being transferred only via HTTPS? When do access tokens expire? Are access tokens in any way bound to the client device or could the same access token be used from a different device, if obtained by an attacker?
I think the Security & Privacy page mentioned by @rigmarole is already a great start, and it helps build my confidence that these important topics are highly valued by the Obsidian team. However, an important part of any security concept is to explain how passwords and/or access tokens are handled on the client side. Therefore, I would really appreciate additional insight.
P.S. On second thought, I don’t see how an access token could do the job: Access tokens might work fine to avoid authentication with a remote service, but to locally decrypt the encrypted data retrieved from the remote vault, you need a password. It has to be somewhere, no? 
The actual encryption key used is derived from the plain-text password you entered.
The plain-text password is not stored. The actual encryption key is stored internally by the Obsidian App.
The actual encryption key is stored internally by the Obsidian App.
I’m wondering how this is done exactly? Are there additional security measures? Because, at the end of the day, all that matters is the encryption key rather than the user-provided password.
1 Like
All it matters for what?
If an attacker has access to your device, they can just read your notes in plain text, no need to bother with Sync.
Even if they were interested in the remote vault, they would need your account credentials (user name, password, 2fa) and the vault password to re-enstablish a connection with a remote vault.
It’s true that the device we use to access a local vault must be a trusted device for the reasons you mentioned. Therefore, it does not really matter whether you store a derived password or the real plaintext password. However, not everyone may be implicitly aware of the technical necessity of storing the password in a form accessible to Obsidian, which is why I believe it is noteworthy and should ideally become an update to the Security & Privacy page.
In the spirit of transparency I think it should be no problem to share some details about exactly where and how the key is stored. “Internally by the Obsidian application” is not quite the level of detail I was hoping for.
Regarding your question why this matters:
Why it matters WHERE it is stored: I created a VeraCrypt container on a USB stick that contains the binaries and the local vault itself. When I unplug that stick or unmount the VeraCrypt volume, will that protect the key as well or is the key stored somewhere in %APPDATA% and I would have to delete %APPDATA% before letting someone else use that device?
Why it matters HOW it is stored: For example, because it could be stolen, if it is stored in a form that is accessible to malicious community plugins. Or maybe thats not even an issue, because the password is somehow bound to my device and would not be usable on a different device.
There will never be 100% security. But knowing and understanding what is going on, helps people account for potential risks.
1 Like
OK, I replied on these concerns in another thread about portable obsidian.
The key is stored in indexeddb (inside appdata folder). If you are concerned about this (and more in general the leaking of matadata about your vault), you should store in your veracrypt vault both the obsidian installation folder and your obsidian vault.
2 Likes
Thanks a lot! 
Just to sum it up:
- Encryption keys are stored somewhere under %APPDATA%\obsidian\IndexedDB, not in the vault itself.
- If I want to keep the keys out of that folder I need to run Obsidian in a sandbox like PortableApps or EnigmaProtector as suggested in the posts linked by @WhiteNoise in this thread: Obsidian Run in Portable Mode?
You didn’t comment on this, but I assume that community plugins could theoretically access any folder on the entire client device, and with enough knowledge of the index, could obtain the encryption key, which could compromise the vault even after the malicious plugin has been uninstalled. Therefore, it is important to take extra care to only use plugins from trusted sources.