-
Notifications
You must be signed in to change notification settings - Fork 57
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
Comments
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 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. |
w.r.t. remote service - are you considering webdav (with custom URL)? Please... w.r.t. passphrase - shall that be
Unless there is a hard requirement in the specs, could be a user choice. |
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. |
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.
The text was updated successfully, but these errors were encountered: