Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

distribution options / vault backends? #14

Open
jo-vf opened this issue Nov 14, 2022 · 3 comments
Open

distribution options / vault backends? #14

jo-vf opened this issue Nov 14, 2022 · 3 comments

Comments

@jo-vf
Copy link

jo-vf commented Nov 14, 2022

I am wondering how one could reuse the same vault accross multiple systems.
I assume with USBIP one could point multiple virtual-fidos to the same virtual usb stick, albeit not at the same time. If instead a database where used or a vault file on a file share, then with proper locking multiple systems can share the same credentials.
Any thoughts in that direction?
Btw. I don´t really like vault being an encrypted file with the key stored within the same file. Imho calls for more trouble than it solves. I´d prefer to rely on user separation and full disk encryption.

@cmdli
Copy link
Contributor

cmdli commented Nov 15, 2022

Right now I am working on a better frontend for this where the vaults are backed up and synced to a remote service and a full GUI for interacting with the FIDO device, but that isn't quite done yet. I would like to make this project able to be easily used by different systems, with the file system storage as just the default in the demo. That is why the user of the library can supply their own FIDOClient interface that can store data wherever they need.

As for storing the encryption key for the vault in the same file, that is more out an abundance of caution than any real extra security. The vault passphrase encrypts the vault encryption key, and then the vault encryption key encrypts the vault, but really the only true secret here is the passphrase itself. The extra vault encryption key is just to ensure that the vault is encrypted with a high entropy key instead of the lower entropy passphrase, but doesn't provide any extra actual security.

@jo-vf
Copy link
Author

jo-vf commented Nov 16, 2022

w.r.t. remote service - are you considering webdav (with custom URL)? Please...

w.r.t. passphrase - shall that be

  • a setting persisted within user data (optionally addressing Using native secret storage #5),
  • asked on first usage via notification GUI,
  • asked every time,
  • or done away with it entirely?

Unless there is a hard requirement in the specs, could be a user choice.

@cmdli
Copy link
Contributor

cmdli commented Nov 18, 2022

Right now in the demo, it's just an arg passed in on startup, and in the GUI that I'm working on, it's just asked once and then as long as the app stays open its stored locally. I would love to better integrate with different forms of secret storage (native secret storage, other passphrase management) and to make the entire thing more customizable, but I'm not sure when I will get to that.

For the remote service, the goal of that part is to create a user-friendly app that regular people might use in their every day, with this project serving as the core implementation of the hard parts that allows users to use different frontends. Again, I would love to make it customizable so that users can use whatever they want, but right now I'm focusing on just getting a single decent implementation up off the ground. That frontend GUI will allow users to be local-only and back up the vault file with whatever means they want, but I can't guarantee exactly how hard that would be; hopefully not too much since it would just be a normal file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants