Given that all password managers have issues, some more severe than others, I've started wondering what a system focused on cross-device sync and family/team sharing would look like if it were agnostic to what data it's storing, such that a password manager could be built as one application of many. Could such a foundation avoid needing any central servers, so nobody has to pay subscription fees that can get redirected to ethically dubious causes, while still being usable for people without a tech background? And how close is SyncThing to being that foundation?
23
Replies
6
Boosts
@jamey syncthing is great, but applications like password storage tend to want to use sql databases which don't play well with simple file sync. So you'd be looking at something that stores in simple files and you probably want it encrypted too.
Personally I use Vaultwarden running on a little home server. It was easy to set up, but I have many years IT consulting behind me so ymmv.
@jamey btw i think the simplest way to do merges is to keep the unmerged contents, until they are explicitly merged. that way the storer can remain agnostic to the contents while not trodding on the toes of the client that might have opinions about how best to auto merge.
@jamey i would really love a theory of difftypes (as opposed to datatypes) that detail how to usefully merge various structures of data
haven't quite invented that yet :3
@monoidmusician aren't CRDTs basically the difftypes theory you're describing?
but yeah, I'm inclined to draw inspiration from https://github.com/39aldo39/DecSync/blob/master/spec-general.md which just has each participant write to a unique location, so there are never file-level conflicts, and then read from everybody else's writes so the application is in control of merging and can ask the user for help if necessary. there are some issues with that spec as written but I think the core idea pretty well does the job here
@jamey@toot.cat
What about a compressed archive encrypted with AES 256?
It let you organize your secrets in folders, is more general then a password manager and can be easily shared between devices over a network (eg on a nextcloud or whatever).
@alcinnz@floss.social
What about a compressed archive encrypted with AES 256?
It let you organize your secrets in folders, is more general then a password manager and can be easily shared between devices over a network (eg on a nextcloud or whatever).
@alcinnz@floss.social
@giacomo @alcinnz Yeah, I'm definitely wondering about things along those lines. For a while I used pass (which gpg-encrypts each password in a separate file) plus SyncThing for synchronized password management between my laptop and phone. (There's an Android app that supports pass files too.) Usability was kinda awful and the privacy properties weren't ideal but as long as it was only for me I didn't care too much. In principle you could share different directory trees with different people and give some people read-only access, so technically this meets all my core requirements.
I think bundling everything into an archive file makes dealing with edit conflicts harder on file-level sync tools like NextCloud or SyncThing, so I'm not sure I'd do that, but I might take inspiration from https://github.com/39aldo39/DecSync/blob/master/spec-general.md instead. Compression also requires some thought since in some contexts compression has caused information to leak from encrypted communications; and while AES256 is fine you need to be careful about choice of block cipher mode, IV generation, and so on. So I'd want a more comprehensive cryptographic specification, preferably vetted by others. But your core idea, that the data should be encrypted at rest and never needs to be decrypted by servers that store backups, is definitely good.
Elsewhere in this thread I've just learned about Ouisync, which does things I like with having separate keys for read and write access, as well as "blind" access where you can verify that you have a correct copy of the data but you can't read or modify it. So now I'm really curious if a password manager with good usability can be built on top of that.
@jamey i would frickin' love an open-source password manager that works across the major client platforms and syncs peer-to-peer when you're in your home
and isn't a fricking bear for "normies" to operate
@brooke yeah! peer-to-peer is possible across NAT, even, as demonstrated by e.g. SyncThing, Tailscale, and WebRTC. in the worst case you need something like a TURN server. since that doesn't need to store anything or understand any app-specific protocol—it just forwards bytes—I feel like that's a reasonable expectation for baseline infrastructure. I guess those examples also all require a known server to rendezvous at in order to share connection parameters, which again is a much lower bar than needing somebody to reliably store your whole password database. so I feel like small efforts in these areas give us a solid foundation for a lot of things, and then people can focus on, for example, good password manager UX and platform integration
it's going to need RBAC-like concepts and an easy way to share or revoke shares of artifacts
@munin I see where you're coming from, but I'm not fully convinced that those are absolute requirements.
for example, BitWarden does sharing by having separate password "collections" which can each have different access lists. you can sort of model roles by associating a collection with a role, but if you want a password to be accessible to two or more roles, you either need to copy it into all the relevant collections and keep them in sync, or create collections for each combinations of roles and keep their ACLs in sync. while it would be nice to have full RBAC, I don't think its absence is a fatal flaw; I think BitWarden's model goes a long way for a lot of use cases.
also, is full revocation important? seems to me like the threat model should be that somebody has a copy of every password you've ever shared with them, so while you naturally need to be able to stop sharing any new changes with them, there's no point pretending you can take away their access to prior data.
the file-sharing tools I've looked at (SyncThing, Ouisync, and most centralized network filesystems) support reasonable user-based access controls at least at the level of a whole folder and all its contents, so for people for whom these compromises are acceptable, there are a lot of tools available to build on.
@jamey@toot.cat this may be of interest: https://www.etesync.com/
It's at least usable with my tasks app
@Filene @amy I was not familiar with Ouisync either, thanks for the pointer! I knew if I posted that toot I would learn things. 😁 I especially like that it supports "blind sharing", which allows you to share the encrypted data with people who are willing to store it for you without revealing the contents to them. so if you want to pay somebody a subscription fee to back up your data and make it always available, you have that option, or maybe you have friends who can do that for you, but it's a service many people can offer. on the other hand I don't immediately see how it addresses edit conflicts, which I think is one of the key questions for sync and sharing, though there are ways to layer conflict resolution on top of simple file sharing if necessary
@Filene @amy After reading the Ouisync paper I'm quite excited about this! Reusing the Bittorrent DHT is inspired. It sounds like edit conflicts which occur in different files are auto-merged in probably the obvious way, so a file structure something along the lines of https://github.com/39aldo39/DecSync/blob/master/spec-general.md could work to ensure that conflicts can be resolved by the application or user.
Next thing I want to know now is: how can browser extensions access these shared files? Is it necessary to install a native app for the extension to talk to or could there be a way for extension JavaScript to sync with peers directly?
@jamey@toot.cat ooh poo for some reason I thought it was open source. Sorry bout that
@Filene @amy looks like it is free software, actually! it's just surprisingly difficult to find the GitHub link on their web site, you have to scroll past all the ways you can give them money first. but the server is AGPLv3, the client libraries are BSD, and the Android app is GPLv3, which all seem like very reasonable choices to me. https://github.com/etesync
@amy it's intriguing, in any case! and they claim to support self-hosting and to have funding from NLnet so I would think it is indeed open source, but I didn't dig that carefully into it. I'm very curious how they're handling edit conflicts; I guess "etebase" is probably the thing I should look at. my only disappointment is that it is architected to require a central server, and if you don't want to pay them a subscription fee your only alternative is to self-host. but based on their FAQ it sounds like they've done more than I expected anybody to do at getting the privacy and security properties right for that configuration—I haven't seen anybody else address trusting a web server to serve you the right JavaScript if you use their web app—so props to them for that. thanks for the pointer!
