Changes to CLI authentication? (Additional authentication required)
gingerlime opened this issue · 18 comments
Describe the Bug
Changes to CLI authentication? (Additional authentication required)
Steps To Reproduce
We've been using the Bitwarden CLI for some time now to manage our server secrets (using envwarden, which I created). Today we're suddenly seeing some strange behaviour when using bw login
user@server:~# bw login
? Email address: email@address.com
? Master password: [hidden]
? Additional authentication required.
API key client_secret:
We use an organization account, and we're a paying customer on the hosted version of Bitwarden.
Also having trouble using the --apikey option.
# bw login --apikey
? client_id: ************
? client_secret: **************
{"response":{"error":"invalid_client"},"captchaRequired":false,"statusCode":400}
Expected Result
Same as yesterday and the last few years? it should work if authentication is successful, be it using email/password, apikey or otherwise. Our password is super long and complex, so even stronger than any client_secret already.
Actual Result
See above
Screenshots or Videos
Environment
- Operating system: Ubuntu 20.04
- Shell: bash
- Build Version (run
bw --version): 1.18.1
Additional Context
Last night we turned on captcha verification for both our login and registration API endpoints on our cloud hosted product. This captcha challenge is required to authenticate if Cloudflare indicates to us your request is likely coming from a bot (here's the code where we do that).
However, we couldn't use our captcha provider, hCaptcha, to challenge CLI auth requests. So, we built in a backdoor to true captcha. The client_secret part of your API key is always a valid captcha response.
It's starting to appear that Cloudflare is consistently flagging CLI requests as bot-originated. That's frustrating, but something we really couldn't test prior to hooking it up to a Cloudflare managed instance.
The Additional authentication is the client_secret part of your API key -- did that not work for you?
The second issue here is a problem with API key auth. I suspect it has to do with bitwarden/clients#2734. Can you try your api key again, but confirm there's no whitespace on either end?
@MGibson1 thank you. This is a really(!) big inconvenience for us to be honest. We relied on Bitwarden for fully-automated server deploys etc, and now suddenly we need to add another secret/key to the mix, which we didn't seed into those servers. I honestly don't quite understand why a (strong) password isn't enough to bypass any Captchas and we need to add another key into the mix ... I really hope that you guys can roll back any changes, at least to give us (and other customers?) some time to adjust workflows.
@gingerlime Thanks for the feedback, and really sorry that this has affected your existing workflows. Given that we don't know if you have a strong master password or not, captcha was a solution to the constant automated brute force attacks that we see on our authentication endpoints. API key authentication via the CLI has been around for quite a while and will bypass the need to use a captcha. I recommend adjusting your workflow to use an API key rather than username and password.
@kspearrin unfortunately --apikey didn't work either... it produced a 400 invalid_client error ... not an authentication error.
I'm not sure I understand the distinction. We do have a strong password, so we're not worried about brute-force attacks on our email/password combos. Why can't we turn-off captcha protection on an account level instead?
This captcha challenge is required to authenticate if Cloudflare indicates to us your request is likely coming from a bot (here's the code where we do that).
Wouldn't Cloudflare likely classify all CLI requests as a bot? it's not a normal browser, but rather a custom API client with custom user-agent etc. I'm not entirely sure how Cloudflare's bot protection works, but off the top of my head, it seems like it might not be the best solution to protecting the CLI from bots. I would imagine it fits protection for sites which are typically accessed by regular browsers?
I think hindsight is 20/20 here.
We don't know how Cloudflare marks requests as likely from bots. I agree this isn't exactly what we were hoping for, we're discussing ways to improve the implementation. What Kyle was trying to point out is that while you have a strong password, we can't guarantee that for everyone, so we feel strongly that this protection is necessary.
An auth method without captcha protection does exist in the form of bw login --apikey. This endpoint we can guarantee the strength of the secrets. Please use --apikey to log in and then unlock your vault with bw unlock.
Yes, I understand. I wish there was an option on the account/user to say "I have a secure password, please bypass Captcha for me", rather than having to change the whole workflow to use an api client id, secret and master password, especially when it offers no security benefit for me as a user of the API.
As the creator/maintainer of envwarden, this also poses a challenge for backwards compatibility.
As a customer of Bitwarden, it also means updating our automated workflows, which adds quite a bit of overhead for something that JustWorked before ... :)
FYI I have been having similar problems in a production process since yesterday. I am using the API key now but will continue monitor this issue.
Let me get this straight... Your documentation recommend to not use the API Key for automated access to vault items per this page: https://bitwarden.com/help/article/public-api/
For automating management of Vault items, we recommend using the CLI. Access to Vault items relies on Vault decryption, which must be done with a Username and Master Password rather than an API Key.
It's also MUCH better to provision things with the least amount of privilege as possible, it's basic security. But your current recommendation (to provide the --apikey) is to suggest a weaker security practice. 🤦
This situation is extremely upsetting because you guys just broke your current working userspace. It's also very upsetting to see the suggested workaround is a weakened security recommendation. It feels like you guys are proving to us that you don't know what you are doing.
I'm not sure it necessarily means weaker security if you use your user client_secret ? It should be limited in scope. So I would definitely avoid using any global API key (please forgive me if I'm mixing terms, I'm not super familiar with how the API keys / scoping works).
However, I definitely feel the pain in terms of usability and breaking backwards compatibility here.
@gingerlime As per the documentation on this page: https://bitwarden.com/help/article/public-api/
Your API key enables full access to your Organization.
It's a major difference. If you access the vault with the API key, it means you have read / write access to users, groups, collections, etc... Mostly it means it has access to everything. You are limited to what that user has access to if you access the vault with the username / password. Which is, not everything.
Thank you. I wasn’t aware of it. I thought the user client secret has the same scope as the one with the master password.
I think the Public API doc might be misleading the discussion. I think @MGibson1's recommendation is that the Personal API Key ought to be used with --apikey, not the Organization Api Key. Use the client_id that starts with user.xxxxxx-... which does as, @gingerlime suggested, have that user's scope rather than a global/organization scope (the client_id which starts with organization.xxxxxx-...).
Thank you @fschillingeriv!
@MGibson1 I don't know if it's a feature or a bug but if I specify --apikey during the bw login command it no longer reads any value for the specified BW_PASSWORD environment variable. The next command, example, bw list items prompt for the password.
@jdecaron did you try bw unlock after bw login --apikey? That command will ask for your password and then give you the session key which you can use to retrieve your items (without having to enter any password or key or 2FA code).
Man these things just happened at the worst moments. This is enough of an issue for me to consider immediately switching to a different password manager.
I updated envwarden so it gives an option to add a client_secret so it continues to work with the latest changes. However, this change also made me realize that Bitwarden is better suited as a password manager than it is to managing server secrets. I therefore decided to stop using the CLI and I stopped maintaining envwarden and archived the project.
At my company, we will continue using Bitwarden for passwords, but not for anything that relies on the API/CLI.
As a maintainer of an (admittedly very small) open-source project that is built on top of the BW CLI, I can't say I'm thrilled with the developer experience. At the same time, I completely understand that I'm not owed anything. It's a huge challenge to maintain such a big open-source project, plus a hosted service which is a juicy target for attackers. I still think Bitwarden is a great password manager. I definitely want to see Bitwarden succeed and thrive in future.
This issue is remediated by bitwarden/server#1626. Interactive sessions now prompt for api key with master password only on the first login of a device.
Note: this server version is not yet released
Until now, we didn't have a good reason to differentiate when to use api keys and when to use username/password other than unlocking. I think we have a good case now to suggest flows which need predictable prompts to use api key authentication + unlock with master password vs direct user interface with CLI using username master password. I'll make sure our documentation is updated to reflect these new recommendations.
I think all-in-all, this is more in line with expected behavior when authorizing external applications to interact with your Bitwarden account and significantly improves account security for all users by reducing the ability to brute-force