A bank safe deposit box offers a different security profile that’s probably more robust against fire because banks burn less often than houses.
It’s probably not practical to really be robust against fire without being buried several feet deep.
In December 2025, items worth an estimated €30 million were stolen from a Sparkasse bank in the Gelsenkirchen suburb of Buer, Germany. The thieves used a large drill to break into the bank's underground vault and proceeded to crack over 3,000 safe deposit boxes.
ex: https://www.cbc.ca/news/safety-deposit-box-protection-1.7338...
https://archive.is/www.nytimes.com/2019/07/19/business/safe-...
It's great if you want to store some documents. But don't expect _real_ security. It's guarded by a minimum-wage employee, and the keys are usually laughably insecure. Banks know this, so they cap their liability for the loss of the deposit box at around $1000.
So don't even think about storing gold bars there, like they do in movies.
There _are_ companies that provide safe storage for high-value items, but they are pretty exotic.
On the internet, it's either: Public for anyone in the whole world, or impossible to recover if anything goes wrong.
In hindsight, looking harder for the key would probably have been fruitful.
Maybe the NSA would be willing to brute force the infinite variations from that starting seed, but it is still effectively locked for mortals.
In a lower trust scenario you could probably use a lawyer as a broker of the secret (potentially even as part of a will).
It would be nice if your Apple account could be unlocked with some other keys as well apart from the primary one, but I guess that is what Apple calls the “Legacy Contact Key”.
Edit: okay so the keychain is excluded from this. So back to storing each others passwords in eachothers keychain…
I like the idea of the lawyer, unlike normal people, they like sticking to their promises.
Also, kudos for packaging it as a static web app. That's the one platform I'm willing to bet will still function in 10 years.
You can discard/modify part of a password before sending it to your backend. Then, when you log in the server has to brute force the missing part.
One could extend this with security questions like how many children pets and cars you own. What color was your car in 2024. Use that data to aid brute forcing.
The goal would be to be able to decrypt with fewer than 5 shards but make it as computation heavy as you like. If no one remembers the pink car it will take x hours longer.
(At home of course, people get pissy if you do this at work!)
I wonder who would not only have the passwords, but the know-how to manage the whole thing, at least to transition it to more managed services...
If you want someone to be able to access it after you’re gone, either put 1000 BTC in it or leave instructions. Paper instructions in a physical fireproof safe is way easier to deal with than any digital encryption with no hints.
You need to give people "a map" of where things are: https://github.com/eljojo/rememory/blob/main/internal/projec...
my zip bundles are 1-2 megabytes due to all the wasm, and you achieved this on so little. impressive job!
I'd love to hear what you think about mine, one of the differences is that it creates a ZIP file containing the recovery app in it, as well as a PDF with instructions for non-technical friends. Overall trying to make the recovery experience as smooth as possible.
but cheers, your version is the only one that I found that does basically what mine does, all the others fall short one way or another!
[0] https://web.archive.org/web/20230610235249/http://bash.org/?...
(If you have a trusted third party, you can also enforce a cooling off period: e.g. that any attempt to access results in a notification to the account holder that if not denied within some time period, access is granted)
However, there is still the issue of the service provider going offline or out of business which we don't have a solution for yet.
We have started with a good password manager and will be adding digital inheritance/social recovery soon! [0]
Take a look, thoughts and feedback welcome.
for the time lock mechanism, how do you go about it? I'm interested in exploring using drand time lock, but that also relies on the service continuing to run (which is admittedly very likely) https://github.com/drand/tlock
This is obviously more cumbersome, and probably costly, if you intend on changing your password. I guess you could change the part of it you don’t store with them.
https://support.apple.com/guide/iphone/share-passwords-iphe6...
https://support.apple.com/guide/icloud/share-files-and-folde...
Thankfully my very long password I use for an encrypted Borgbackup I have was somewhere deep or untouched, but, otherwise I would have been fucked. Also, the backup codes Google told me they would always accept failed and it wasn't until I found a random unused Android device in a drawer that had been unused for a year was I able to get access back to my Google account of ~25 years.
this exact story is why i built my app, thank you so much for sharing.
my hope is to basically make a next version of your plan that's distributed among friends.
One practical problem to consider is the risk of those distributed bundles all ending up on one or two major cloud provider's infra because your friends happened to store them someplace that got scooped up by OneDrive, GDrive, etc. Then instead of the assumed <threshold> friends being required for recovery, your posture is subtley degraded to some smaller number of hacked cloud providers.
Someone using your tool can obviously mitigate by distributing on fixed media like USB keys (possibly multiple keys to each individual as consumer-grade units are notorious for becoming corrupted or failing after a time) along with custodial instructions. Some thought into longevity is helpful here - eg. rotating media out over the years as technology migrates (when USB drives become the new floppy disks) and testing new browsers still load up and correctly run your tool (WASM is still relatively new).
Some protocol for confirming from time to time that your friends haven't lost their shares is also prudent. I always advise any disaster recovery plan that doesn't include semi-regular drills isn't a plan it's just hope. There's a reason militaries, first responders, disaster response agencies, etc. are always doing drills.
I once designed something like this using sealed paper cards in identified sequence - think something like the nuclear codes you see in movies. Annually you call each custodian and get them to break open the next one and read out the code, which attests their share hasn't been lost or damaged. The routine also keeps them tuned in so they don't just stuff your stuff in an attic and forget about it, unable to find their piece when the time comes. In this context, it also happens to be a great way to dedicate some time once a year to catch up (eg. take the opportunity to really focus on your friend in an intentioned way, ask about what's going on in their life, etc).
The rest of my comments are overkill but maybe fun to discuss from an academic perspective.
Another edge case risk is of a flawed Shamir implementation. i.e. Some years from now, a bug or exploit is discovered affecting the library you're using to provide that algorithm. More sophisticated users who want to mitigate against that risk can further silo their sensitive info - eg. only include a master password and instructions in the Shamir-protected content. Put the data those gain access to somewhere else (obviously with redundancy) protected by different safeguards. Comes at the cost of added complexity (both for maintenance and recovery).
Auditing to detect collusion is also something to think about in schemes like these (eg. somehow watermark the decrypted output to indicate which friends' shares were utilized for a particular recovery - but probably only useful if the watermarked stuff is likely to be conveyed outside the group of colluders). And timelocks to make wrench attacks less practical (likely requires some external process).
Finally, who conducted your Security Audit? It looks to me as if someone internal (possibly with the help of AI?) basically put together a bunch of checks you can run on the source code using command line tools. There's definitely a ton of benefit to that (often the individuals closest to a system are best positioned to find weaknesses if given the time to do so) and it's nice that the commands are constructed in a way other developers are likely to understand if they want to perform their own review. But might be a little misleading to call it an "audit", a term typically taken to mean some outside professional agency is conducting an independent and thorough review and formally signing off on their findings.
Also those audit steps look pretty Linux-centric (eg. Verify Share Permissions / 0600, symlink handling). Is it intended development only take place on that platform?
Again, thanks for sharing and best of luck with your project!
Tell someone you trust about where you left these pieces of paper.
I would be in an impaired state, and cannot function in way that would be conducive to either work or pleasure in terms of computer use.
That is to say, the entire reason why I have password security at all is to keep out people who do not know the password. If someone does not know the password, they should not be able to access the system. That obviously and clearly applies to myself as much as any other person. "If you do not know it, then you do not need it."
The important thing is to ensuring your computer is not a single point of failure. Instead of losing a password, you could have theft, flood, fire, etc. Or for online accounts, you are one vendor move away from losing things. None of these should be precious and impossible to replace. I've been on the other side of this, and I think the better flow is to terminate or transfer accounts, and wipe and recycle personal devices.
A better use of your time is to set up a disaster-recovery plan you can write down and share with people you trust. Distribute copies of important data to make a resilient archive. This could include confidential records, but shouldn't really need to include authentication "secrets".
Don't expect others to "impersonate" you. Delegate them proper access via technical and/or legal methods, as appropriate. Get some basic legal advice and put your affairs in order. Write down instructions for your wishes and the "treasure map" to help your survivors or caregivers figure out how to use the properly delegated authority.