mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-04-26 01:35:54 +03:00
[GH-ISSUE #560] 2FA - error on login #361
Labels
No labels
SSO
Third party
better for forum
bug
bug
documentation
duplicate
enhancement
future Vault
future Vault
future Vault
good first issue
help wanted
low priority
notes
pull-request
question
troubleshooting
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/vaultwarden#361
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @iurab on GitHub (Aug 7, 2019).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/560
With latest release I can not pass the 2FA security check. It just stays on that page.
In the log, the following error is reported:
[2019-08-07 13:06:54][bitwarden_rs::error][ERROR] JsonError. {"TwoFactorProviders":[0],"TwoFactorProviders2":{"0":null},"error":"invalid_grant","error_description":"Two factor required."}@dani-garcia commented on GitHub (Aug 8, 2019):
What two factor provider are you using?, Any error messages on the browsers console?
@iurab commented on GitHub (Aug 9, 2019):
I use the 2FA with Authenticator App.
When I pass the master password and arrive at /#/2FA url:
POST https://xxx/identity/connect/token 400 zone.js:1152@Ryonez commented on GitHub (Aug 13, 2019):
I'm having the same issue, though I'm getting a 504, Gateway Timeout.
@Ryonez commented on GitHub (Aug 15, 2019):
@dani-garcia
Just had a user who's Bitwarden chrome extension got corrupted. They've repaired it, however because of the two factor issue they can't sign back in with it.
Thankfully they have a valid login through the web portal, but I feel this issue needs to be escalated now.
@dani-garcia commented on GitHub (Aug 15, 2019):
The U2F problems are separate from this issue I think, usually caused by either an invalid
DOMAINconfiguration or certificates that aren't accepted.The 504 errors sound more like a proxy issue, as far as I know.
I'd make sure that the time in both the client and the server are in sync when using TOTP Authentication, if that fails as a temporary measure you can remove the 2fa from the account by editing the database directly, but that can be prone to errors.
Sadly I won't be home until the 19 to test and possibly fix this. Is the bug just with the latest version? Can you go back to an old version to test again? (Make a backup before doing that, as going back in versions isn't supported)
@Ryonez commented on GitHub (Aug 15, 2019):
Testing on my end:
504 Error
As far as I can make out that's what the reverse proxy is returning (it manages the certs) as the bitwarden_rs container is timing out during the 'https://vault.alteria.xyz/identity/connect/token' POST
TOTP Time Sync
Checking the time between the server, the bitwarden_rs container and my computer, the time is completely in sync.
As to if the bug is just in the latest version, I do not know. I've only recently found it after seeing this post and testing myself to confirm. Unfortunately this was still a problem when my user's chrome extension had issues.
This is also a live service on my end atm, I can't readily revert a version to testing without interrupting the service. Easiest way to check would be to spin up a new container with an older image to test sorry.
@Ryonez commented on GitHub (Aug 15, 2019):
Wow, I found after writing that up that more was added to the logs around 10 mins later, and it looks related to the TOTP issue::
@gstammw commented on GitHub (Aug 16, 2019):
You are absolutely right.
I saw the same problem with bitwarden_rw 2.11.0 on a self-hosted installation:
Within the docker-container, there’s a file /web-vault/app-id.json:
root@89d7996a4efd:/web-vault# cat /web-vault/app-id.json { "trustedFacets": [ { "version": { "major": 1, "minor": 0 }, "ids": [ "https://vault.bitwarden.com", "ios:bundle-id:com.8bit.bitwarden", "android:apk-key-hash:dUGFzUzf3lmHSLBDBIv+WaFyZMI" ] } ] }Within the docker container (
docker exec -it bitwarden.service bash), I had to modify the url in that file and usedsed -i -e ‘s/vault.bitwarden.com/bitwarden.myhost.com/g’ /web-vault/app-id.jsonI should have read the instructions better, especially point 9 on modifying app-id.json.
Can you please review my update of the manual on the installation of bitwarden_rs in docker, specifically on enabling U2F: it only mentions to se the DOMAIN-value to a proper url, but additional modification of the app-id.json-file is required.
Maybe this gap derived from the bitwarden source itself, as several users reported it in the bitwarden-forums.
@Ryonez commented on GitHub (Aug 21, 2019):
Any progress? This is kinda urgent, the user having issues is one I finally convinced to shift away from keypass.
@dani-garcia commented on GitHub (Aug 21, 2019):
@gstammw There's no need to modify that file, we serve the correct contents from here, instead of modifying the file:
github.com/dani-garcia/bitwarden_rs@d23d4f2c1d/src/api/web.rs (L31-L47).@Ryonez @iurab I've tried to debug this and it seems to work fine for me so I'm not sure where the failure comes from.
Two things:
The error
[ERROR] JsonError. {"TwoFactorProviders":[0],"TwoFactorProvide ...is expected, that's how the server communicates to the clients that user and pass is not enough and the clients need a second factor. Try to see if there's any error after this one, or in the browsers console.I've added in
github.com/dani-garcia/bitwarden_rs@026f9da035a button to the admin panel to remove the second factors from a specific user, if everything else fails, the admin can remove them to let the user log in.I'll try to look into this more.
@Ryonez commented on GitHub (Aug 21, 2019):
Thank you.
Later on today I'll clone my instance's database and spin up another bitwardenrs container to step back through the versions to see if I can find a spot it isn't an issue.
Regarding disabling a users 2FA, will there be any adverse side affects?
About later errors, I did find some, they were posted above.
@dani-garcia commented on GitHub (Aug 21, 2019):
Yeah, it's basically the equivalent of logging in as a user and removing them one by one.
Hmm, I just saw the latest errors, and they don't make much sense, they are making a GET request to the login endpoint, when it should be a POST request:
In fact I just checked the web vault code, and they only make POST requests to that endpoint, so no idea what could be causing that ¯\_(ツ)_/¯
@Ryonez commented on GitHub (Aug 21, 2019):
Alrighty. I'll disable this user's 2fa for now, then clone, do some testing later and get back you you with the results.
@Ryonez commented on GitHub (Aug 21, 2019):
Okay.
To start with, the issue isn't with TOTP itself, it's somewhere else in the code.
Dropping back to version 1.9.0 breaks login completely. It'll say I have an incorrect username/password, doesn't even get to the TOTP stage.
Going back to my main instance, I disabled TOTP, then re-enabled it. This hasn't helped.
Interesting notes:
@Ryonez commented on GitHub (Aug 31, 2019):
Figured it out on my end:
There doesn't seem to be many checks if the email system fails. It'll either timeout or return unknown errors. And it's present all the way back to version 1.8.0
There also isn't any error posted to the logs, which made diagnosing this much harder. I'd recommend popping something in so it goes into the log at least.
@dani-garcia
For @iurab, check your email settings are valid!
@Ryonez commented on GitHub (Aug 31, 2019):
Looks like this may have been the cause. New setting for me, but wasn't disabled by default.
In fact that whole section of the admin page only started working once I fixed the email settings.
@sgabe commented on GitHub (Sep 24, 2019):
I just ran into this issue as well. I was able to login again after I removed the e-mail configuration.
@Ryonez commented on GitHub (Sep 25, 2019):
@dani-garcia We may have found the cause.
@Ryonez commented on GitHub (Oct 5, 2020):
Was this looked at for solutions to prevent this in the future?
@BlackDex commented on GitHub (Oct 5, 2020):
Well, it should already be
falseby default, so don't know how we can improve this any further.Since it does state if the e-mail fails, to login fails, so that will be the consequences of having that checkbox enabled.
@Ryonez commented on GitHub (Oct 5, 2020):
Looking up above one of the problems was that the email component was silently failing.
Having that would be an improvement for those who wish to enable email configuration.
If that has been changed all good, just there's not commit or comment about that change here if it's happened.
@BlackDex commented on GitHub (Oct 5, 2020):
Well a lot has been changed regarding email handling.
So, if sending fails you should receive an error, or at least in the bitwarden.log file. If you still have a specific scenario where this isn't the case we can try to fix them of course.
If you have some cases we can reopen this of course.
@Ryonez commented on GitHub (Oct 5, 2020):
Sweet as, thank you for responding.