Application password is recoverable from data.json — key stored next to the ciphertext

[Kjeld76]

Not really a bug, more a heads-up about how the application password is stored.

In data.json the plugin keeps encryptedPassword.key, encryptedPassword.vector and encryptedPassword.encrypted next to each other in the same object. So the key needed to decrypt the password sits right beside the ciphertext. Anyone who can read that file can recover the password — the encryption doesn't protect against that, it just makes it non-obvious at a glance.

The reason I think it's worth mentioning: that file lives inside the vault. Plenty of people sync their vault through Dropbox, iCloud or Syncthing, or keep it in a git repo. In those cases the WordPress credentials travel along, and they don't look like a secret to anyone reviewing what's in there. A vault that ends up public would leak them without anybody noticing.

I don't know what the right fix looks like for a cross-platform Obsidian plugin — as far as I can tell there's no OS keychain access from the plugin API, so there may not be a good place to put it. But even just a line in the README saying the password is recoverable from data.json, and that the folder shouldn't be synced or committed, would help. At the moment it reads as if it's encrypted at rest, which is what made me look in the first place.

Checked on 0.18.0. Happy to be corrected if I've misread it.

[Kjeld76]

Following up on my own report — I had only looked at the field names in data.json when I opened this, which wasn't good enough. I've now read PassCrypto in main.js, and the picture is a bit sharper than what I wrote.

encrypt() generates a fresh AES-256-GCM key, exports it, and returns it alongside the ciphertext:

const key = await crypto.subtle.generateKey({ name: AES_GCM, length: 256 }, true, ["encrypt", "decrypt"]);
const encrypted = await crypto.subtle.encrypt({ name: AES_GCM, iv: vector }, key, ...);
const exportedKey = await crypto.subtle.exportKey(FORMAT_JWK, key);
return {
  key: JSON.stringify(exportedKey),
  vector: this.bufferToBase64(vector),
  encrypted: this.bufferToBase64(encrypted)
};

All three go into data.json, and decrypt(encrypted, key, vector) imports that same JWK straight back. In my own file the key field is a valid JWK with kty: oct, alg: A256GCM, key_ops: ["encrypt","decrypt"] and 43 base64url characters of key material — so it really is the key itself, not an identifier or a salt. Recovering the password is a couple of lines against the file.

There's also a fallback I hadn't noticed. When WebCrypto isn't available:

return { encrypted: this.reverseString(this.stringToBase64(this.reverseString(message))) };

That's base64 with the string reversed on both sides — encoding, not encryption, and there's no key next to it because none is needed. decrypt mirrors it. On desktop Obsidian canUse() should be true, so this probably doesn't trigger in practice, but the stored shape is then indistinguishable from an encrypted one unless you look at whether key is present.

None of this is a break of AES — the crypto is fine, it's the key handling. Which is why I still think a note in the README is the most useful thing here: whatever the storage looks like, anyone who can read data.json can read the password, so it shouldn't sit in a synced or committed folder.