Username or Password are incorrect. Try Again

[pfr-dev]

rbw 1.10.2 installed using Cargo (on NetBSD).

I've successfully run rbw register and have entered my client_id and client_secret, received email confirming I'd connected from new device

Set my email address in config (redacted) -- yes, it's correct!

~ λ rbw config show
{
  "email": "xxx@xxxx.xxx",
  "base_url": null,
  "identity_url": null,
  "notifications_url": null,
  "lock_timeout": 3600,
  "sync_interval": 3600,
  "pinentry": "pinentry",
  "client_cert_path": null
}

Try to login and I get this, everytime.

Even after running rbw purge and killall rbw-agent then trying to login again

~/.cargo/bin is in my users PATH

[pfr-dev]

Thank you! this fixed it.

I've just installed it with cargo install --git https://github.com/doy/rbw --rev b133675. Hopefully this will be merged soon.

[benjamb]

@thimc Thanks for the fix! That seems to get things working for me once again.

Out of interest, what happens with bitwarden's CLI? That might have a slightly more appropriate client_id string than browser.

[thimc]

@thimc Thanks for the fix! That seems to get things working for me once again.

Out of interest, what happens with bitwarden's CLI? That might have a slightly more appropriate client_id string than browser.

No problem :)

Perhaps, it looks like they are using the same client_id as the one you're supposed to enter when you register the device. ( For reference https://github.com/bitwarden/clients/blob/main/apps/cli/src/auth/commands/login.command.ts#L92 ). If we were to do it that way we would need to store that ID to a file. I am not familiar with how rbw works in general so I don't how if this is something it already does.

[latipun7]

Thank you! this fixed it.

I've just installed it with cargo install --git https://github.com/doy/rbw --rev b133675. Hopefully this will be merged soon.

I have the same issue. Trying to install rbw the same way above, still have no luck. Successfully rbw register and have email confirmation, but failed on rbw login.

EDIT: it's work. Thank you

[pfr-dev]

@latipun7 Did you kill rbw-agent & rbw purge ? Or just rbw-purge then reboot

[thimc]

@latipun7 Yeah like @pfr-dev said, you will probably need to purge the data and kill any existing agent process. I also removed the cache files at ~/.cache/rbw and ~/.local/share/rbw before I tried logging in again. I would also check the config (rbw config show) just to be sure that everything is alright.

[latipun7]

Sorry for the trouble 🙏, it's works. I just forgot to uninstall rbw v1.10.2, and seems cargo bin path below that, so I'm still using original v1.10.2, not from cargo bin🤦

Thank you, @thimc, for the PR

[pfr-dev]

I figure I'll leave this issue open until this patch is merged. Feel free to close it once it is. I'll let the NetBSD pkg maintainer know once there is a new release tag so it's can be updated in pkgsrc.

Cheers

[machenity]

Thank you! this fixed it.

I've just installed it with cargo install --git https://github.com/doy/rbw --rev b133675. Hopefully this will be merged soon.

Hi, I've tested the build of this revision, this fixed the issue on intel mac, but arm(m1 pro) mac still has the issue even with this revision.

[yasn77]

Thank you! this fixed it. I've just installed it with cargo install --git https://github.com/doy/rbw --rev b133675. Hopefully this will be merged soon.

Hi, I've tested the build of this revision, this fixed the issue on intel mac, but arm(m1 pro) mac still has the issue even with this revision.

I am in a similar situation... But I have it working on M1 Mac but for the life of me, I can't get it working on Linux (Manjaro). Tried the following:

• Downgrade to 1.9
• Upgrade to official 1.10.2
• Used @thimc PR branch

(Between trying these, I cleaned out rbw... rbw purge, rm -rf ~/.config/rbw, rm -rf ~/.local/share/rbw... Also ran rbw registerafter cleaning out).

It's a little annoying as it's difficult to debug... No real debug logs/messages and I was hoping to try and use mitmproxy but there is an open issue in regard to rbw not honouring proxy env var.

I use rbw with chezmoi as it's super convenient not having to worry about BW_SESSION.... Really hope this can get fixed, not looking forward to going back to bitwarden CLI

[pfr-dev]

Ok, I tried to sync my database on my Void Linux machine and it's broken again. Installed the b133675 revision, re-registered and still it will not log in.

I tried rotating my keys but still no dice :(

[thimc]

Ok, I tried to sync my database on my Void Linux machine and it's broken again. Installed the b133675 revision, re-registered and still it will not log in.

I tried rotating my keys but still no dice :(

Weird, it's still working just fine for me. I'm on OpenBSD though, have you tried removing all the cache files and whatnot to see if that helps with anything?

[Lcchy]

Same for me sadly (on NixOS 24.05), I am getting the same error with the patch applied.

Could this be Cloudflare blocking access based on some weird bot classification?

[pfr-dev]

Weird, it's still working just fine for me. I'm on OpenBSD though, have you tried removing all the cache files and whatnot to see if that helps with anything?

Have you tried rbw sync ? I'm cautious to sync the database on my NetBSD system as I have no other way of accessing my passwords on there and really dont want to have to build firefox just so I can use the extension.

Could this be Cloudflare blocking access based on some weird bot classification?

Hmmm possibly, I'll try again and check the DNS logs

EDIT I use NextDNS and it doesn't appear that anything is getting blocked when I try to log in.

[jonestristand]

Any progress on this? I am having the same error despite successful rbw register and using the PR version above...

[dezeroku]

Official CLI app seems to use cli as the client_id for its request, it's worth trying @jonestristand I'd say it seems more adequate than browser for rbw's case anyway

[jonestristand]

Official CLI app seems to use cli as the client_id for its request, it's worth trying @jonestristand I'd say it seems more adequate than browser for rbw's case anyway

Unfortunately this does not fix the problem...

[jonestristand]

Shouldn't it be using the client_id provided to rbw register rather than 'cli'?

[dezeroku]

I believe that it depends on the login strategy you're trying to use.

If you're using the password flow (without registration) then there's no unique client_id to use, so things like cli,desktop and browser sound ok, as it seems they are used to recognize the client type on Bitwarden's end.

If you're using the registration flow (with api key) then indeed the client_id used is taken from the API key you provide.

Looking at the rbw's code it seems that only password flow is supported for the logins (as in, you can use API key to register the device, but not to login currently).

[jonestristand]

Hmm this seems to be in contradiction to the README which states you need to register prior to logging in. If this functionality is not working then it seems like rbw is non-functional at present for use with the official BitWarden servers?

[dezeroku]

The rbw register command works fine on its own and uses the client_id and client_secret (apikey from Bitwarden) that you provide to it. If I got the logic right, it logs in to Bitwarden servers, so they recognize your device_id that's generated on rbw's first start, but it doesn't save any token for future use. In other words, if you run rbw register you still have to follow it up with rbw login to actually get your vault.

Now the rbw login currently only supports logging in via email&password combo. There's ongoing work on the authentication via SSO, but I haven't found an issue for APIkeys based logins (as possible with official CLI's bw login --apikey).

BTW rbw register is recommended to avoid being detected as a bot by Bitwarden, but I'm not sure if it's a hard requirement. I recall being able to just rbw login on new machines, probably depends if you get lucky and won't flag Bitwarden's security :shrug:

TL;DR I don't think that rbw currently supports logging in with only API keys, still email and password are required. We'd use key's client_id and client_secret if apikey based login would be in place, but for the email&password flow we stick with more generic cli/desktop/browser

[pfr-dev]

I wish I could be of more help here, and I don't want to sound ungrateful for the work and free time everybody has contributed to this project, but I have to ask... is there a solution in sight?

I really rely on Bitwarden for my passwords, and so far on 2 out of the 3 systems I run, rbw is broken (the 3rd only works because I refuse to sync) and I'm now reliant on the Firefox Browser extension for accessing my passwords. I really hope there is a fix for this soon.

Thanks to everyone contributing. I may not be able to contribute but I'm happy to test patches :)

[jonestristand]

The rbw register command works fine on its own and uses the client_id and client_secret (apikey from Bitwarden) that you provide to it. If I got the logic right, it logs in to Bitwarden servers, so they recognize your device_id that's generated on rbw's first start, but it doesn't save any token for future use. In other words, if you run rbw register you still have to follow it up with rbw login to actually get your vault.

Now the rbw login currently only supports logging in via email&password combo. There's ongoing work on the authentication via SSO, but I haven't found an issue for APIkeys based logins (as possible with official CLI's bw login --apikey).

BTW rbw register is recommended to avoid being detected as a bot by Bitwarden, but I'm not sure if it's a hard requirement. I recall being able to just rbw login on new machines, probably depends if you get lucky and won't flag Bitwarden's security 🤷

TL;DR I don't think that rbw currently supports logging in with only API keys, still email and password are required. We'd use key's client_id and client_secret if apikey based login would be in place, but for the email&password flow we stick with more generic cli/desktop/browser

I don't totally follow. If I run rbw register I successfully get a new device email, but running other commands such as rbw sync asks for my password and then fails with Username or Password are incorrect. Try Again. I don't get an option to interact with bw data without trying to login, which fails...

[pfr-dev]

I successfully get a new device email, but running other commands such as rbw sync asks for my password and then fails with Username or Password are incorrect. Try Again. I don't get an option to interact with bw data without trying to login, which fails...

This is exactly my issue and I do not believe changing the client_id from desktop to cli resolves the issue. Well, it did initially, but it didn't last long. Perhaps I'll rotate keys and try once more but I have done this already with this revision and it's still broken.

Perhaps Bitwarden needs to incorporate "app passwords" similar to some email services which allow you to use IMAP/POP3 etc with 3rd party apps (Fastmail does this).

[dezeroku]

The thing is that rbw register logs you into the Bitwarden server, but doesn't keep the auth data locally, so you still have to rbw login to actually access the vault with commands like rbw list or rbw get. In other words, Bitwarden server gets to trust the device that you have just logged in from (as it knows the device id now), so it shouldn't ask you to solve the captchas anymore. But that's it, the purpose of rbw register is solely to notify Bitwarden that it should trust the device you've just logged in from and not treat it as a brute-force bot.

The rbw login command on the other hand gets you the tokens that can be used later on with rbw sync and it actually downloads the vault from the server.

So now, when you run rbw register you log in with the API key provided by Bitwarden -> and that's working But when you run rbw login you log in with the email and password (as that's the only implementation we have right now) -> and that seems to fail for you

So really the rbw register working does not necessarily mean that rbw login should work too, as they authenticate with different credentials.

Under the hood, the register and login commands hit the same endpoint of /connect/token with very similar parameters, so it should probably be possible to implement the rbw login based on apikeys, but based on this commit it seems it's not trivial. Hopefully something has changed on the Bitwarden's end since then, as the official CLI supports logging in with API keys.

I know that this isn't really helpful for you guys @pfr-dev , @jonestristand , but at the very least it means that the APIkey based auth is working for you. Maybe this calls for a need to support APIkey based logins in rbw too.

Does the above sound right @doy ? I could play with the idea after the SSO is done

[pfr-dev]

but at the very least it means that the APIkey based auth is working for you.

It's useless if I cant actually access my passwords.. And unfortunately the official bw cli isn't supported on BSD :( ..and it's still a pain to use on Linux.

[dezeroku]

It's useless if I cant actually access my passwords..

It's not useless if you get someone to implement the apikey based login. I've managed to write a dirty PoC, here's how to test it:

1. add client_id and client_secret entries to rbw's config file (this should be changed before putting this into an MR)
2. Download, build and run the code

   cargo install --git https://github.com/dezeroku/rbw --rev a55b68b
   # Make sure that the newly built version is actually first in PATH, something like `which rbw`
   killall rbw-agent
   rbw purge
   rbw login

   rbw login will see that client_id and client_secret are defined in the config and attempt apikey based login.

rbw will ask you for the master password when you run this command, you can write whatever you want in that field, its value doesn't really matter at this point. if you get the rbw login: failed to unlock database: Password is incorrect. Try again. message at the end just run rbw unlock and it'll work.

rbw login will set you up for an hour, after this time passes you'll have to run rbw purge && rbw login manually again (this should also be implemented properly before putting this into an MR). Appropriate error message should tell you when it's needed.

I've tested this locally and works fine with the list and get commands at least, I didn't test any further.

BTW, regarding the issue with current main's rbw login, did you see any interesting info in either ~/.local/share/rbw/agent.err or ~/.local/share/rbw/agent.out?

What's technically going on under the hood

When you use apikey based logins, bitwarden doesn't allow you to set the scope to offline_access, so you don't get the refresh_token as part of the response. Official CLI seems to just rerun the login process and obtain new access_token every time the validity runs out. This PoC attempts to do roughly the same, it's just not automated at this point. Also that's why I've opted for keeping the client_id and client_secret in the config file, they are reused roughly every hour. In the final implementation we'd probably want to keep it encrypted (maybe with the master password?) in the DB or something (at least the secret part).

[pfr-dev]

Thanks. This works. So, is this something that is going to be merged into main ?

did you see any interesting info in either ~/.local/share/rbw/agent.err

[2024-06-18T02:47:37Z WARN  rbw_agent] failed to disable PTRACE_ATTACH, agent memory may be dumpable by other processes: unimplemented on this platform
pinentry-curses: no LC_CTYPE known - assuming UTF-8
pinentry-curses: no LC_CTYPE known - assuming UTF-8
failed to sync: failed to load db from /home/dave/.cache/rbw/default:my@email.com.json: No such file or directory (os error 2)
failed to sync: failed to load db from /home/dave/.cache/rbw/default:my@email.com.json: No such file or directory (os error 2)
[2024-06-20T12:39:29Z WARN  rbw_agent] failed to disable PTRACE_ATTACH, agent memory may be dumpable by other processes: unimplemented on this platform
pinentry-curses: no LC_CTYPE known - assuming UTF-8
[2024-06-20T12:42:52Z WARN  rbw_agent] failed to disable PTRACE_ATTACH, agent memory may be dumpable by other processes: unimplemented on this platform

[dezeroku]

is this something that is going to be merged into main ?

Definitely not in the current form, but I don't see a reason why a proper MR wouldn't be accepted.

1. Securely storing client_secret
2. Properly changing the refresh token flow, so it performs a relogin if the apikeys are used

These two problems will need to be addressed correctly.

I'll try to work on it when I get some free time

[pfr-dev]

Legend! And yes, I feel a bit scetchy having my client_secret in a plain text file... but it'll have to do for now. If you do publish any future revisions let me know and I'll happily test.

[jonestristand]

Interesting... was not aware client_secret and client_id could be stored in the config file...