{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifeer5uuofmh2qij7nnxy5ooiswdsxrplkfstytabshvgelexzlcm",
    "uri": "at://did:plc:haakkg7y3xdghcdmprxeexso/app.bsky.feed.post/3mlhkdlclyqq2"
  },
  "path": "/t/master-password-backup/37745#post_13",
  "publishedAt": "2026-05-09T23:18:39.000Z",
  "site": "https://discuss.privacyguides.net",
  "tags": [
    "rubber hose cryptanalysis"
  ],
  "textContent": "lyricism:\n\n> I would hope people who are privacy and security conscious would use a secure random method to generate their master passwords\n\nDon’t think there’s consensus on whether passwords _must_ be “securely random” (it is great if they are)? It is fine the way password managers vend them out, with sufficient _entropy_. May be you mean the same thing, or may be I misunderstand (and I am totally wrong…).\n\nlyricism:\n\n> A pure something you know factor is not as inherently easy to compromise as a pure something you have factor.\n\nPersonally, I prefer shredding cryptographic material than suffer rubber hose cryptanalysis.\n\nlyricism:\n\n> Not if your master password that encrypts all the other passwords is truly a knowledge factor.\n\nPassword managers better have “escrow” mechanisms and not be reliant on a single knowledge factor… In fact, I would refuse to use any scheme (in any important setting) that wouldn’t support escrow keys (like Android FBE / Ente do).\n\nColter:\n\n> I don’t want to have a single point of failure.\n>\n> I want to spread the backup\n\nThere’s nothing about “writing it down” that’s a single point of failure. You can write (the escrow keys, not the password) those down twice and store it in two separate safe locations (like in a safe/hardware-vault). Break the (ideally, 32 byte uniformly random; 64 hex chars) escrow keys into 4 parts (of 8 bytes; 16 characters each) and store it in 8 different locations. Not saying these are what I’d do… I’d simply write down the escrow keys once, and put in a safe. Rotate (invalidate the previous escrow key for a new one) the escrow key (or the seed that generates multiple escrow keys) every once in a long while, if the scheme supports it.\n\nRoyal:\n\n> At least on Android, it shows a notification if some app copies the clipboard.\n\nAnd…? Android (the OS) prefers it does not have to “handle” master secrets… forget about “relying” on it to throw a notification when an adversary exfiltrates secrets.",
  "title": "Master Password Backup"
}