99% of my passwords are stored in a password manager.
To encrypt the vault I obviously need a master password, which I memorized and practice regularly to not forget it.
But maybe I could forget my master password.
So I need to backup it somehow.
I don’t want to have a single piece of paper where the master password is just written down, because if someone finds this, he could directly decrypt my .kdbx file and read all my passwords.
So I did some research and decided to make a Shamir Secret Sharing.
But the problem is that I can’t find a tool where I can put in my master password and get out multiple shares of words.
All the tools I found, either only accept Hex values, or make undesirable (for my purpose) outputs, like QR codes or Hex values.
I just want to enter words and get words back that I them can write done on multiple papers.
Does someone have a solution?
How do you backup your master passwords?
Been thinking about something similar recently. OnlyKeys interested me with their support for far more static passwords than Yubikeys.
I think YK is still considered the gold standard but if I’m just throwing an OnlyKey with a few static passwords into a home safe / safe deposit box / etc. for disaster recovery it seems fine. You can put a PIN on it and give that to a friend maybe.
Despite from them being closed source, this still wouldn’t solves OP’s need for decentralized protection against memory loss.
They are also a single point of failure.
Write it down on paper and keep it in a safe. It is a good idea to have a water and fireproof safe for important stuff such as your passport, birth certificate, and in this case, a written master password.
Get a security key that encrypts the contents against a PIN or a password. Trezor wallets and OnlyKeys are the only options I’m aware of that meet this criteria. Avoid YubiKeys because they do not encrypt stored data and completely depend on potting.
Writing down is a good practice as @Lukas points out. Ideally, what you’re writing down isn’t the password itself.
The password manager may provide a way to securely recover the vault through high-entropy escrow keys (typically, 32 bytes; 64 hex characters), which are enrolled by the user & can be rotated at will (while the user still remembers the password). These escrow keys are written down somewhere and kept safe in lieu of the password.
I strongly advise against writing down the master password itself. You would be turning a “something you know” factor into a “something you have” factor by doing that, which on its own is weaker than a properly random “something you know” factor and means you are unlikely to ever really be able to protect your password manager with MFA since most second factors are already “something you have”.
If really needed you could split it with Shamir’s Secret Sharing into 3+/n parts and give one each to a trusted party who wouldn’t be likely to collude with another to harm you. That sounds more complicated than it is, the parties could just be a biological family member, a friend, and a partner, for example. Usually people’s relationships of those kinds are such that there’s not really any risk of all three coming together to scheme against you in this way, but obviously make sure that’s the case in your situation for whoever you choose.
Just make sure whatever tool you use to split the secret is used entirely offline.
My solution to this was Yubikey on the file and https://2of3.ente.com/ for the physical backup of master key. If you dont have a Yubikey there is another option where you can use a file as a second factor. What a lot of people don’t realize is that this file can be a photo or a text file with a passage or phrase. So as long as you know you have a back up you can select a family photo or something. However what I noticed is that I think it saves the hash of this file for autologin which I didn’t like and selecting the file every time was also annoying and felt like it didn’t give that much more security. I have become more concerned about Malware and keyloggers and it didnt’ make sense to me that unlike an online password manager the Keepass file didn’t have a second factor. So I think Yubikey is the best option. It is easy to back up the HMAC secret key so you won’t lose access to the file if you lose or damage the yubikey.
The problem with any scheme that requires you to import the master key is… it is no longer a private secret. For instance, when you “copy” the key, it is in the clipboard of whatever OS you’re using, and there’s no shortage of apps that monitor the clipboard. Take extreme care with secrets, and never export them from which ever silicon they’re generated on without “wrapping” them. In the wake of ubiquitous adoption of computationally strong & fast cryptographic constructions, the focus has shifted to compromising keys instead.
Passwords aren’t usually “properly random”. Besides, transitioning from “something you know” to “something you have” isn’t bad for security (password managers are firmly in the latter category, as are passkeys, which additionally have strict domain separation).
Kind of right. Absent access to hardware-backed vaults, it is okay to write down high-entropy escrow keys (or inputs that can ‘expand’ to 100+ 32-byte keys with a single random-seed & a high-entropy secret) that are revocable/rotate-able without fuss with the main password (which isn’t written down).
Agree with this in general, but I would hope people who are privacy and security conscious would use a secure random method to generate their master passwords. I recognize that is just a hope, of course. Maybe it is worth being more clear that my advice hinges on that specifically.
This isn’t really true. With a “something you know” factor, you can know every time it was disclosed if you care to keep track of that level of detail. With a pure “something you have” factor, it could be stolen while you sleep, for example, and returned before you wake without you even realizing anything happened.
A pure something you know factor is not as inherently easy to compromise as a pure something you have factor.
No? Not if your master password that encrypts all the other passwords is truly a knowledge factor. In that case you could consider it a knowledge and possession (of the encrypted data) factor, but since you can’t access the encrypted data without the knowledge factor it is much moreso reliant on the knowledge factor.
Passkeys can and should require user verification like e.g. a PIN which makes them a combination knowledge and possession factor. Passkeys which don’t require any verification beyond possession are less secure than secure passwords alone, of course.
Don’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…).
Password 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).
There’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.
And…? 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.
I think the issue is just that you can’t really measure entropy of a non-random password. Cryptographic entropy is a property of the mechanism by which the password was generated, not the password itself. That’s why a passphrase of x characters has less entropy than a password with x characters. If someone creates a password that’s just their name any entropy estimate will be inaccurate. You need a secure random method of generation for any entropy estimates to be accurate.
Yeah, but that makes them use a combination of factors, they don’t purely use a possession factor either. Maybe I misunderstood your point though and you were saying that they involve a possession factor rather than just a knowledge factor? Which yeah I agree with in the case of offline password managers to some extent, although in all cases I think they are designed so that the security model doesn’t rely at all on the possession factor of the vault itself.
Does KeePass prefer printable characters (seems like)? If so, by definition, the password (even if chosen at random) doesn’t cover all UTF8/UTF16 code points and hence cannot said to be “uniformly random”. That said, I could be I am mistaken, as I am not a cryptographer.
Key management is the hardest thing in cryptography.
Escrow keys can be rotated out and/or disabled. Ideally, these are 32-byte random & have strict domain separation; that is, one-time, context-specific use: You’re not typing it anywhere or copypasting it everywhere, for example (like you would be your password when using the password manager or any other application).
Yeah I mean if you write it down then an attacker would need to a) get it b) know what it is and c) have the 2FA which is presumably enabled.
I would just try and have a master passphrase you could remember. 5 or 6 words is secure.
If you wanted, you could have your master passphrase stored an a kdbx keepass file, that only unlocks with a keyfile, and then keep 2 or 3 USB drives with the keepass file somewhere, with the keyfiles in seperate locations.
I know for crypto wallets they have these bolts that you can put a phrase on and then drill it into concrete.