Changes to CLI authentication? (Additional authentication required)

[gingerlime]

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

[MGibson1]

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?

[gingerlime]

@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.

[kspearrin]

@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.

[gingerlime]

@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?

[gingerlime]

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?

[MGibson1]

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.

[gingerlime]

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 ... :)

[micottis]

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.

[jdecaron]

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.

[gingerlime]

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.

[jdecaron]

@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.

[gingerlime]

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.

[fschillingeriv]

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-...).

[jdecaron]

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.

[micottis]

@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).