Apart from the usual (strong A/V), are there any best practices to prevent against browser (I have to use Chrome for work) and/or extension/add-in exploits?
I update the extensions weekly and ensure that Chrome updates daily. Being that BW is implemented via an extension, this seems critical. There are a few extensions I have to use for work so I have more than I might like and I know that increases threat surface.
Any thoughts are appreciated!
My suggestions would be:
Disable auto-fill on page load.
Tailor the URI match detection rules to be as narrow as possible (so that autofilling works only on the login and password change forms, but nowhere else in the domain).
Perhaps extreme (but I do it): Disable all (or most) other browser extensions.
Only log into to your vault when you actually need usernames/passwords, get what you need then log out. Don’t leave your vault sitting unlocked.
Excellent suggestions. In regards to the URI match detection rules, how does the default URI match detection setting factor into that? Is there a setting that is best/safest?
In the event I can’t disable other browser extensions, is there a runner-up approach?
Might any other extensions help with security in that regard such as uMatrix or CookieAutoDelete? Or do those pertain to other attack vectors?
Simple, effective, elegant. I like it and easy to miss!
Undoubtedly a safe approach, but may be overkill for most. If your master password is sufficiently strong (5-7 diceware words), then it is very safe to leave the browser extension logged in, as long as you lock it when not in use.
For the average user, I would take your advice but substitute “log into” → “unlock”, and “log out” → “lock”.
If you feel that you need to reduce your attack surface by completely logging out of the app when it is not in use, then I would probably also recommend the following safeguards:
Close the browser (or kill the Bitwarden process) immediately after logging out.
Use only on a system that is protected by whole-drive encryption.
Disable hibernate and swap files.
Immediately delete any .DMP files created by the OS.
Periodically run sdelete.
The safest, but most cumbersome approach, is to individually set the URI match detection rule for each store URI in each login item (e.g., in the browser extension, click the 
icon next to the URI), and not rely on the default setting.
The safest setting is Exact, but it doesn’t always work (for example, if the parameters appended to the end of the URL change each time that you visit the login page, then you will never get a match). The next safest setting is Starts with (assuming that your stored URL extends past the / that follows the TLD & optional port number), which you can use if you delete the part of the URL that changes when you revisit the same page.
Using the above options usually takes some fiddling if there are multiple different entry points for logging in to a given service, which have different URLs. Usually, I end up storing several URI entries in the same vault item to account for this.
Depends on what you mean by “can’t” (don’t know how to disable, or cannot work without access to other extensions). I usually work in Incognito mode, which only allows browser extensions that have been explicitly authorized.
Basically, allow only those extensions that are you trust and that are necessary.
For the URI match detection rule setting, wouldn’t base domain protect against populating malicious sites in every case except when the site you’re logging into was hacked? If it’s the “right” domain, that seems secure in other cases but I don’t know enough to say for sure. In either event, I’ll follow this guideline (exact or starts with) as I move forward.
I didn’t think extensions even worked in Incognito mode in Chrome. Maybe I need to switch browsers! What is the advantage of using that mode when working? Mitigating auth / session cookie theft?
I have the browser set to clear all cookies on logout and will learn about the other suggestions. I don’t know if there’s a way to simply disable hibernate / swap / .DMP files but I imagine there is.
What files would I be having sdelete delete? Would weekly be good enough or is daily better?
Thanks again!
To be clear, my recommendations in that response were only for the ĂĽberparanoid. The sdelete recommendation is related to the challenges in securely deleting data that exist in the unused space on an SSD.
It depends on whether owners of the base domain allows subdomains that may be controlled by individuals other than the owner (e.g., dynamic DNS).
A legitimate website may contain ads, trackers, analytics, or other embedded third-party content, which could access content that you auto-fill. Thus, the fewer webpages on which you allows auto-fill to work (within a given domain), the lower your risk exposure will be. This is especially critical for users who enable Auto-fill on page load.
Thanks! I’m not uber paranoid, just security-minded…so maybe those other ideas would be overkill. I’m glad to learn though and know that they exist…and will look into them at least so I can understand.
Last question!
Can you kindly reply to the query pertaining to Incognito mode?
“I didn’t think extensions even worked in Incognito mode in Chrome. Maybe I need to switch browsers! What is the advantage of using that mode when working? Mitigating auth / session cookie theft?”
The main security benefit is that it doesn’t load browser extensions that haven’t been explicitly authorized. Other than that, it’s mainly just an old habit on my part, that shouldn’t necessarily be emulated.