A readable password in an internal system is serious. It should not, however, automatically unlock the most private data a person has stored. Separating account authentication from content decryption limits how far one failure can travel.
The password logging lesson
Meta disclosed in 2019 that some Facebook and Instagram passwords had been stored in a readable format in internal data storage. Its security update shows why authentication secrets deserve strict handling even when there is no evidence of external access. For a journal, the next question is whether that secret can also decrypt years of private writing.
Account authentication is not decryption
Inpages stores an account password as a one-way password hash for account login. That mechanism establishes an authenticated session. It is deliberately separate from the Vault Password used to derive a key for Protected Memories, so normal account authentication code does not need the data-decryption secret.
The browser vault path
The browser derives a key from the Vault Password with Argon2id, then uses it to unlock an Encrypted Master Key. The Master Key encrypts and decrypts Protected Memory fields and protected file bytes locally. Rails can store the encrypted Master Key and ciphertext without receiving a usable plaintext Master Key. The architecture note traces that flow in detail.
Social sign-in needs the same separation
A Google-only account creates a separate Vault Password for Protected Memories. That avoids treating an OAuth session as sufficient permission to derive the content key. It also lets the product state the boundary clearly: a sign-in provider may help authenticate an account, but it does not hold a person's journal decryption key.
Recovery must not become escrow
A support reset that could always recover protected writing would mean the service holds a recovery route to the Master Key. Inpages instead lets the owner export a Recovery Key in the browser. The Recovery Key design explains its verifier and why the key is never uploaded as a support secret.
What separation cannot solve
Separate secrets reduce the consequence of some server-side authentication failures. They do not protect an unlocked browser from malware, a malicious extension, XSS, screenshots, or a person using the device. They also do not make weak passwords safe. This is a defense boundary, not a promise that one password incident has no consequence.