It’s their No. 1 selling point.
> In 50 years time, who knows if any of these companies will be around
1Password has local clients. If you have the password, you should be able to unlock the vault locally.
It’s their No. 1 selling point.
> In 50 years time, who knows if any of these companies will be around
1Password has local clients. If you have the password, you should be able to unlock the vault locally.
I have installed the "1password-cli" package on my airgapped linux machine with no network access ('op --version' gives me 2.30.3).
If I run 'op vault list', it tells me I have to add an account. When I run 'op account add' it tries to connect to 1password's servers and won't let me proceed without internet.
I don't see how this "local client" is helping if all the auth infrastructure goes through their servers.
Is it possible to export as a file, take that with you on whatever medium (eg. USB key, CD-ROM, future isolinear chip), put it on a brand new PC you built from scratch and never connected to the internet, and open it in some kind of standalone viewer?
Originally it was an app with no remote component. The vault was yours to look after. Most people kept it in Dropbox to make it accessible anywhere. The vault itself actually had an html file in it that you could open in a pinch that was able to decrypt secrets (only for reading, from memory).
1Password as a service came later.
Dropbox came later and security minded folks were wary. Honestly, I trust 1Password sync more than an encrypted db on a general purpose cloud file sync, but maybe that’s naive.
Super contrived, but you could probably just copy the sqlite dbs of your vault it creates locally to another PC along with the 1Password installer and it might let you sign in with just your master key.
It's truly local first and will work fine in an airgapped situation.
It's also designed to be self-hostable[2], is open source [3] and the API is well documented[4].
[1] https://saveoursecrets.com/ [2] https://saveoursecrets.com/docs/cli/self-hosting/ [3] https://github.com/saveoursecrets/sdk [4] https://docs.rs/sos-sdk/latest/sos_sdk/
Passwords, even ssh keys and passkeys, are little pieces of plain text. If you think needing a specialised sdk or cli to retrieve plain text is a good software architecture, I think we see the world quite differently.
We clearly see things differently but I think using computers to make our lives easier is worthwhile and storing/managing our secrets securely, effectively and conveniently is better managed by software than some ad-hoc setup.
Nitpick, passkeys are not text, they are binary blobs.
Because I feel pretty confident that gpg will still be around (though hopefully long deprecated), that gzipped files would still be able to be opened, and everyone would still be able to open a csv file. Without any specialised software, sdk or whatnot.
If this scenario doesn’t concern you, that’s fine, 20 years ago it wouldn’t have been my concern either. But the older I’ve become, the more I think about this stuff.
Pick the formats your storing and handle security at the container. This might be an encrypted system that is copied and updated over decades or a physical storage safe or box.