I know bitwarden has its servers on Microsoft’s azure and there are about 100k rounds of encryption but given the Authy and Lasspass hacks how safe are we? What additional steps have been taken to ensure that these hackers won’t be able to touch bitwarden’s files. If you did not know hackers got into Authy servers and ACCESSED 2FA codes(which means they BROKE the encryption and got in) that get generated every 30 seconds. They could also get their own device REGISTERED in those accounts as legit devices.
Any comments from the bitwarden security team will be appreciated.
Change your password(keep it complex) and start using 2fa preferably Microsoft authenticator/Google authenticator. Also keep a secure back up of the 2fa recovery code in Google authenticator and keep you outlook account safe in case you are using Microsoft authenticator.
This is a serious claim, and I have not been able to find any reliable source to verify what you are saying. Can you provide a source that verifies encryption of users’ authentication tokens was broken to allow access to 2FA codes?
So it seems that 2FA codes were not compromised unless one or more of the 93 affected users also had their backup password stolen or brute-forced. Is there any evidence that this has happened?
Nonetheless, the next logical question would be: To what extent is the Bitwarden Authenticator susceptible to a similar attack? Is there a way to backdoor additional devices, and if so, are the authenticator tokens protected by additional security measures?
Thanks for the discussion it’s good to stay vigilant! Just sharing a response I posted to a similar question recently:
Code changes do not get automatically pushed through to the live environment.
Aside from being openly available on Github for community review, proposed changes to the Bitwarden codebase undergo automated scans and require manual layers of code review by different team members.
We also work with security researchers at HackerOne to identity potential issues, and Bitwarden is subjected to regular third party audits.
Even if a third party were to get one of your 2FA codes, they wouldn’t be able to take action on it without your master password, which is required to decrypt vault data.
@bw-admin Can you share anything about the security of the Bitwarden Authenticator? In the unlikely access an attacker gained access to Bitwarden’s servers, would they be able to carry out actions similar to those that occurred at Twilio? For example, could they add authorized devices, and would they be able to sync authentication tokens using an added device?
Bitwarden authenticator data is stored within the vault, which is locally encrypted before being sent anywhere, so even if someone got access to the server where the blob is (and severs have many layers of detection and protection), they wouldn’t be able to interact with the data without your master password to decrypt the information.
So, according to Twilio’s limited explanation thus far, combined with their description of Authy’s security setup, logic would have us assume that the 93 compromised accounts 1) must have had “allow multi device” enabled, 2) must have been accessed with sms via sim swap, 3) previous TOTP codes were not accessible, due to the requirement of the backups password to decrypt those.
All that being said, it’s hard to tell what’s what. Twilio has not been fully forthright regarding exactly how those 93 accounts were compromised. They have not clarified whether those accounts had “allow multi device” enabled or disabled. They also have not commended on whether already-present TOTP codes were able to be accessed.
If any of those accounts had multi device disabled, that would mean there is a gaping hole in Authy’s security setup. Further, if any of those accounts had their TOTP codes accessed, that would also mean that there’s a giant issue with their backups encryption and/or their explanation of how their security works.
Because Authy is closed-source, users’ only option is to take them at their word, as their security claims cannot be verified. And until Twilio is more transparent about the specifics regarding this attack, I would not trust them with anything.
Not quite. They sent phishing texts to Twilio employees, masquerading as Twilio’s IT staff, asking them to change their passwords by following a URL in the texts. Some of Twilio’s employees fell for this and basically handed over their usernames and passwords to the hackers.
Phishing/social engineering is still one of the biggest sources of breaches, the Bitwarden team, among other many other security trainings, undergoes phishing simulations to keep this top of mind.
One method of good practice to combat phishing is instead of putting our personal information on platform. here are some of my basic ones i go by:
use privacy information such as privacy forward email addresses that auto-forward your emails to your primary email address,
also separate personal emails from secure email address account (ex: facebook, reddit, etc use personal privacy forward, for bank account and more secure like bitwarden use a seperate secure email address)
do NOT click links in emails, this is key unless you know how to validate email addresses and ensure it looks valid and is legit, this ensures you no rerouted.
verify the website links you are on. use a web browser that show the full url, not url shorten version, and verify SSL certs.
5., DO NOT GIVE OUT INFORMATION, ONLY CONFIRM with trusted contacts, if in doubt go to the website or example banks go in a location.
Good list. Along with those types of common sense measures to protect private info and make sure you’re not fooled into entering your credentials in the wrong place, there are additional measures that might protect you even if you do get fooled:
Use your bitwarden browser extension and fill the username / password from there (NOT copy paste). It will not manually or auto fill unless it is talking to the correct site. In fact you’ll notice even earlier that bitwarden extension doesn’t auto-pull up the credentials unless you are on the right site.
Use hardware token (Yubikey) where allowed for 2FA. It will not authenticate unless it’s talking to the correct site. Bitwarden TOTP may provide this feature too, I’m not sure but I use a separate TOTP app so if I’m fooled into entering my credentials I might also be fooled into typing my TOTP code into the same site.
Of course nothing is 100%. Can a sophisticated man in the middle can fool your browser extension and yubikey into thinking they’re talking to the right site? Beats me.
NO – cannot be done! Yubi and other physical keys are supreme. There are several great articles around the net for why keys leave “man in the middle” dead in the water. Google has discussed why employees are required to use physical keys in order to COMPLETELY eliminate the problems with phishing!
Your browser extension can certainly be fooled if you don’t have the URI match detection options set up properly to exclude possible irrelevant matches. For example matching https://domain.com using Starts with would cause the browser extension to match and autofill on the malicious site https://domain.comehere4vir.us; matching https://safelogin.dyndns.org using the default option (Base domain) would cause the browser to match and autofill on the malicious site http://safe1ogin.dyndns.org; and all sorts of trouble could result from using an improperly configured regex with the Regular expression option.
In the realm of servers getting hacked, I don’t believe MFA adds any extra security.
I believe it is only the master password that is used to encrypt the vault.
Hackers who have accessed the servers and got the encrypted vaults will be able to access your vault with your master password alone even if you use a yubikey etc.
and such a hack is inevitable. Underlines the supreme importance of a strong master password and don’t rely on MFA.
I am pretty sure you are correct. The issue is not with U2F physical keys but rather the code used here with BW. My interpretation and understanding is that the physical keys used with BW only prevent your individual “blob” from being downloaded from Azure servers. This is why the keys are so valuable regarding MITM prevention. IF someone already has your Azure “blob” (from a global Azure hack) then and only then is your Yubi key rendered of no value.
This code could be changed, but anyway, this is my “read” on its application here.
