How can I protect my Bitwarden account from brute-force attacks?
A: A brute-force attack is when a malicious actor cycles through a combination of weak and short passwords in an attempt to gain access to your account. Bitwarden offers a few ways you can protect yourself from these potential attacks:
Have a long and unique master password. Bitwarden requires a 12 character minimum to increase account security.
Set up 2FA on all Bitwarden accounts to add an additional layer of security.
Bitwarden will require CAPTCHA verification after 9 failed login attempts from an unknown device.
We do not indeed, if i’m correct this is not active for self-hosted instances, even the Bitwarden Self-Hosteds).
We do have a rate-limit on this, so that should prevent brute-force attacks.
See:
2. Vaultwarden can’t send emails on failed login attempt?
We currently do not indeed. We do for successful logins from unknown devices.
But this is a nice feature to add, ill put it on the list.
That’s right, now the limit on the number of login attempts is triggered on failed login attempts.
What should I specify for LOGIN_RATELIMIT_SECONDS and LOGIN_RATELIMIT_MAX_BURST so that after 10 failed login attempts, the next one will be in 5 minutes?
This is a great option. We hope it will be added soon. Thx.
If i’m correct from the top of my head that would be: LOGIN_RATELIMIT_SECONDS=300 LOGIN_RATELIMIT_MAX_BURST=10 And i set 10 here, but keep in mind that since you use 2FA, which causes the clients to call that endpoint a second time within those 5 minutes.
Also note, we do this for every attempt, not only failed logins, because someone could also try to use invalid logins or try multiple etc…
So, this does mean that if you login from the same IP on 5 different devices which all need to enter a 2FA within 5 minutes, that after that you can’t login anymore, and need to wait for 5 minutes to try again.
Does this work for the IP-account vaultwarden mapping?
For example: I have 50 users, they who log in from the same IP (NAT) in vaultwarden. User (user1@email.com) entered 10 times wrong password. Will only user1@email.com or all users get login restriction (5 minutes)?
It’s per IP. Nothing else is used to match it.
Else an attacker could just switch between multiple accounts if they know more accounts on a specific deployment exists.
As per the meta thread, I think it would be a good idea to allow email notification on failed attempts, just like we get email notifications on successful attempts.
If this is just a notification about a failed login, how can that be abused?
Wouldn’t the rate limit then kick in. At least at that point hey I know there’s some failed attempts going due to notifications and I’m already working on shutting it down to the outside world until it can be looked into more.
This failed attempt notification can be configured with a Boolean ENV variable, and default can be set as false. If someone wants to receive such emails of any failed login attempt, they can enable this feature. This will resolve your concern of getting spam emails. That way I would know someone found my instance and using my email with wrong password attempts to get in and I can take my server offline or take necessary actions. The email will also log the attempter’s IP address, so I will know where the requests are coming from, and add access rules on my proxy server to block that country or similar.
Don’t you think this will be very useful for the privacy concerned user base of Vaultwarden? Thanks a lot for keeping this amazing project going, it’s truly AMAZING!
Great idea to add rate limits. I use fail2ban to monitor Vaultwarden’s logs for multiple failed attempts and ban the IP after it reaches the threshold. Fail2ban bans the IP at the network level so the attacker can no longer reach Vaultwarden’s instance. I get notified from fail2ban via e-mail when it bans someone along with full info from the IP using Whois by IP service.
Fan2ban also monitor /admin page and bans anyone who tries to access it from the outside. I’ve already set the IP restriction on apache to only allow /admin access on the LAN.