-
-
Notifications
You must be signed in to change notification settings - Fork 1
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
bitwarden: check local env vars for password or api key #11
Comments
Looks like this can be accomplished via using the according to: https://bitwarden.com/help/cli/#using-an-api-key
to get the api-key you have to login to the web-vault via bitwarden.com.. From there you need to click on the user icon at the top-right of the page and select Next you'll need to select the At the bottom of the page you should get the options to view the key: Enter your password at the following screen, and get your api key Then export the bw login --apikey
You are logged in!
To unlock your vault, use the `unlock` command. ex:
$ bw unlock |
Amazing writeup, thank you! :D |
no problem! 🥳 |
Checked and it looks like even with the api key, you still need to enter in the password to unlock the vault. I don't knoow that we're gaining anything by introducing the API key :(
|
Well, it's hacky, but we can maybe suggest local users use libsecret to grab their bitwarden password and then export that in their shell on login, and then that can be used to unlock the vault. So, going back to the default option for this ticket: We should check local env vars for password. More importantly, it might make sense to add a "add to vault command" option, where we can add things to your vault of any password manager of your choice, but this would still require the user to know that they need to export certain env variables ahead of time to have the vault command work 🤔 I hate this for us. D: I wish that the API key actually worked like a normal API key and didn't still require the password key. This feels like it just adds complexity and no extra security, because you can't even set "require api key". |
Reopening because although we now check for session tokens in the env vars, we do not accept API keys yet. |
#45 is semi related to this. |
I guess if the user is not logged in already, we could potentially try logging in via an api key, but after that, I am closing this ticket, because this is a lot to handle for the scope of this project currently. |
No description provided.
The text was updated successfully, but these errors were encountered: