Assessing Security & Safety vs. Convenience for Log In & PIN Options

[Mycenius]

I am looking for help in completely fully understanding the convenience versus risk ramifications of using the various log in/lock/2FA options and use of Master Password & PINs in the various app types of BW. So would appreciate any guidance from the more experienced or technically skilled members of the community as its my last step before I jump ship completely from 1PW to BW.

Also wanting to understand for these if there is a difference in the risk between a desktop version (in Windows & macOS) vs. extensions (various browsers on both Windows & macOS) vs. the mobile app (specifically iOS as I don’t use Android) for these functions. I do understand with regard to other products like LP (and a couple of others I think) they made the desktop the most robust app followed by mobile apps (I think) and browser extensions were the least secure as the browser environment was supposedly the most secure to start with and desktop considered where the greatest threats were – does BW have similar logic?

So, I’m looking to understand how much the risk or threat level increases if you enable certain convenience issues? I had hoped there might be a bit of a white paper or similar on this taking you through the options with some sort of guidance on best practice (likely annoying to do) vs. a couple of levels of convenience & scale of the related risk; but only found the basic info in the FAQs plus what I could from several threads here (I’ve quoted a few for reference below).

1. On log In to your BW app/vault what is the risk with selecting remember me for your email address?
Does this make it easier in any way for a bad actor who gains access to your device remotely to potentially access the vault data (and is that subject to the other choices below)? If so how (is the email address stored locally encrypted somewhere)? I assume if they physically gain access to your device (remotely or physically), it may increase the risk (possibly dependent on the other choices below)? Also is the risk different depending on whether it’s a Desktop app, Browser Extension, or Mobile app and/or what the O/S is? FWIW I have a unique email address I use only for my Password Manager and nothing else (and via an encrypted mail server/provider), so if this is exposed somewhere it undermines trying to keep it discreet.

2. Remembering the 2FA Authenticator Code for App/Vault Log In is safe?
If I have understood what I‘ve read correctly (from some other posts on the subject) and what I previously knew it’s not essential to force re-entering this 2FA code every time you log on (subject to other choices in this list of questions) and the risk may be acceptable if physical loss of your device likelihood is low; as this only verifies your login and you still need your master password which is also what unlocks the vault? As its main purpose is to stop someone trying to access your vault from a completely new/different device that isn’t one of your regular ones I assume the increased risk is very low for taking the remember a device or browser option? Or is this risk different for a browser extension vs. Desktop or Mobile app? I have been doing 2FA with 1PW for sometime (with the remember device equivalent) but hadn’t thought in depth about all the ramifications until recently planning moving over to BW….

3. Enabling Unlock with PIN?
I’ve read with interest much of the discussion around this in some of the other threads – from what I’ve gathered ‘in theory’ there is not an ‘exponential’ increase in the risk if doing this (although there is presumably some increase) as the master password is stored locally (in memory or encrypted on disk?) for the PIN to access and therefore not accessible remotely (in theory). Is the risk different depending on whether it a desktop app, extension, or mobile app? However, I assume due to the next item below and the known issues PIN use is temporarily a disproportionately increased risk if used (at least in some configurations)?

4. Lock with Master Password on Restart option when using PIN (NOT Vault Timeout)
I will always enable this as want to ensure Master Password is re-entered every time app is accessed for first time (e.g. device restarted, Browser restarted/reopened, etc). But it is mentioned in the thread What do “keyHash”, “encKey”, and “encPrivateKey mean in data.json regarding the desktop app (where the json file doesn’t get deleted when this option is deleted), and looks to be an issue for (some) Browser Extensions (in Chrome at least, albeit for different reason?): Questionable PIN Security - this bug currently leaves the vault exposed on the local device (the Chrome Browser Extension saves vault in persistent local storage after logging out and exiting Chrome (on Github). So this means vault is left on local disc exposed and if vault was copied off the device (or the device stolen, etc) it could then be brute forced relatively easily as it would only be locked not logged out – as only PIN not Master Password is securing it? So right now this function shouldn’t be relied on in the Desktop app nor the Chrome Browser Extension – so perhaps PINs shouldn’t be used at all for now on desktops to be safe? (I am assuming iOS Mobile App is likely fine and this is not an issue for it to use PINs; but other browser extensions on desktop I haven’t seen anything nor had opportunity yet to try and do my own basic testing of any so should assume a possible risk for now?)

5. Vault Time Out – Lock vs. Log Out
I always select a time period for these types of settings (typically in the 1 to 15 mins range depending on the device) – but if using a PIN I would normally aim to select ‘lock’ not ‘log out’ – that’s normally the point of the PIN, right? If master password on restart is enabled for PIN (see above) and working as designed (as opposed to the current known issues linked to above) what resident risks are there from only locking the vault vs. logging out of it. Obviously, it exposes the vault if it somehow gets copied off the device while in that state, but are there any other risks - in theory it should be in memory the whole time its decrypted correct - but what about when its locked? And should this option (if used) be set differently on a mobile device (or portal desktop like a MacBook or Windows Laptop), that is more likely to be ‘physically’ lost or stolen, than a non-portable desktop (like a PC which you are only likely to ‘physically’ lose if you have a major burglary at your location, etc)? e.g. should you always set log out on mobile/laptop regardless vs. using lock on a static desktop?

6. How much risk does downloading the Website Icons really present?
Is this just a minuscule ‘privacy’ (only) risk or is it a meaningful potential security risk? As an aside this I believe could be easily remedied by allowing manually imported unique icons that are stored in the vault (somewhat like 1PW does – see FR Custom icons for items and folders/collections) for example; but in the meantime, what is the view on the risk? And if the icons are cached unencrypted locally as discussed in one thread (Is there any security or privacy issue with the bitwarden web vault retrieving site icons?) does this mean, for now, there is a meaningful security (as opposed to privacy) risk? How much does having these visual indicators of websites empower/assist a bad actor?

Any guidance or technical advice or commentary will be greatly appreciated.

[grb]

With regards to the PIN, it does not have to be numeric, so it can be as long as complex as you want, and it could even equal your master password (in which case you gain zero convenience vs. unlocking with the master password, but you also give up zero security). So the way to think about the PIN is that by setting it to something weaker than your master password, you are giving up entropy for convenience.

With regards to locking vs. logging off, locking should be fine unless you have poor physical security for your devices. Locking purges the decrypted vault from memory, but leaves the encrypted vault on disk; logging out purges the vault from both memory and disk. There are a few vestigial issues with clearing of the memory in some situations, but if you are worried about those, you can terminate the Bitwarden app process. If you have a sufficiently strong master password, there should be few if any negative repercussions of your encrypted vault being stolen from the local device.

With regards to the email, the main risks are that if someone decided to target you, they could attempt to break in to your email account, and if successful (e.g., if your email account has a weak password and no 2FA), they could potentially delete your Bitwarden account. The other risk is that they could attempt a brute-force attack by repeatedly logging in with guessed passwords; this would obviously fail if you have a strong master password, but you may get annoyed and/or unnerved by the notifications you will receive about filed login attempts. The third risk is that someone who knows your Bitwarden login email could target you with a spearphishing attack to trick you into revealing your master password.

[Mycenius]

Thanks as always for taking the time to respond @grb,

@grb

With regards to the PIN, it does not have to be numeric, so it can be as long as complex as you want, and it could even equal your master password (in which case you gain zero convenience vs. unlocking with the master password, but you also give up zero security). So the way to think about the PIN is that by setting it to something weaker than your master password, you are giving up entropy for convenience.

Yes I appreciate BW gives you a lot of flexibility with the PIN and in can effectively be a surrogate password, however as we both agree you sacrifice convenience in that case. In my case I’m looking at PIN use specifically from the aspect of a 6-8 character ‘quick access’ function to unlock vault while actively using a device (over a period of time). On a desktop/laptop I’d expect to logout regardless if device or app is shutdown (or browser closed if its an extension); or if device times out and locks/goes idle (e.g. where screen saver or lock activates after ‘x’ minutes of inactivity). So I’m not looking at it necessarily as keeping the vault always locked (and logged in) and using PIN for ‘first access’ each session (so its the sole protection)… Obviously on some newer machines you have biometrics as an option (e.g. my macBook Pro) which eliminates the need for a PIN ‘in my usage case’ - although with browser extensions it’s not quite as convenient right, as you need to open the main desktop app first anyway to enable the biometrics…

Obviously with a mobile device it’s a little different, and you generally have biometrics and/or integral O/S PIN by default as part of the access routine.

@grb

With regards to locking vs. logging off, locking should be fine unless you have poor physical security for your devices. Locking purges the decrypted vault from memory, but leaves the encrypted vault on disk; logging out purges the vault from both memory and disk. There are a few vestigial issues with clearing of the memory in some situations, but if you are worried about those, you can terminate the Bitwarden app process. If you have a sufficiently strong master password, there should be few if any negative repercussions of your encrypted vault being stolen from the local device.

Cheers - yes I was thinking desktop use of locking via PIN was probably less of a concern because (a) for personal use device is more secure if its in your own home (especially if a true desktop vs. laptop/portable), and (b) is probably better hardened against external/remote intrusion due to security software, etc?

So to be clear the ‘locked’ encrypted vault on the disk is still only protected by the PIN right, which comes back to your original comment at start about a PIN being a surrogate password rather than just a short ‘convenience’ access code… or do you mean here “if you have a sufficiently strong master password, there should be few if any negative repercussions of your encrypted vault being stolen from the local device” that its logged out when locked so regardless of PIN strength it’s secured? If not the latter then the vault’s only going to be secure when using a shorter PIN if its not lifted from the local drive by an intruder?

@grb

With regards to the email, the main risks are that if someone decided to target you, they could attempt to break in to your email account, …could potentially delete your Bitwarden account. The other risk is that they could attempt a brute-force attack by repeatedly logging in with guessed passwords… third risk is that someone who knows your Bitwarden login email could target you with a spearphishing attack to trick you into revealing your master password.

Thanks - yeah I was thinking some form of either 1 & 2 were the obvious risks - but I do use a unique address specifically for my password vault (albeit an alias of an account that has moderate use via a different address); and all my email accounts have strong passwords and 2FA enabled by default. Hadn’t thought about the spearphishing angle, but normally pretty good at spotting those though or being suspicious of emails asking for information verification or to log in to your account for vague or generic reasons (like shipment update when you haven’t ordered anything)…

I had theorised there might be one other set of benefits - as for example if they stole the vault (from local storage), along with other data off the machine, and (if the account email was set to be remembered to save re-entering it each time) that gave them knowledge of the email for the vault’s account would that not significantly aid them in cracking the vault - especially of trying brute force approach?

[grb]

@Mycenius

So to be clear the ‘locked’ encrypted vault on the disk is still only protected by the PIN right

No, this is only the case if you explicitly enable the option to Unlock with PIN (in which case my caveats about PIN-based locking apply). The default behavior is to lock/unlock with the master password.

@Mycenius

that gave them knowledge of the email for the vault’s account would that not significantly aid them in cracking the vault - especially of trying brute force approach?

The account login email is stored (in cleartext) in the data.json file, so if they have stolen your local vault, then they have your email.

[Mycenius]

Thanks for clarifying @grb

To confirm you are saying it is in the vault in clear text always, regardless of whether you have the ‘remember email’ option enabled for logging in?

[grb]

Yes, that’s my understanding. You can check it out for yourself, by opening the data.json file (location of file varies by client and OS — see here).

[Mycenius]

Thanks @grb - will test that out.

[bwuser10000]

Good thread, thanks for posting. I need to read this in its entirety tonight and let it sink in. I too have been weighing the benefits of safety and convenience. On my phone, I already have Lockdown mode available if needed so I’m good with biometric unlock along with a very short Bitwarden unlock duration. And my phone password is pretty long and complex.

For the Bitwarden app and web interface, ideally I’d like a selectable short period before locking then another selectable, longer period, after which I’d be locked out.

[Mycenius]

@Mycenius

6. How much risk does downloading the Website Icons really present?
Is this just a minuscule ‘privacy’ (only) risk or is it a meaningful potential security risk? As an aside this I believe could be easily remedied by allowing manually imported unique icons that are stored in the vault (somewhat like…

As an aside - curiously - it turns out my current PM only stores the manually uploaded images (icons) in the encrypted vault, and any you leave to ‘auto-update’ from the web are left outside exposed in your cache or such…:

Icons you add to your items… are encrypted with the rest of your data. However, the rich icons that are automatically downloaded are not encrypted. - from Protect yourself when using rich icons

[BBA]

Good thread. I am in the midst of the transition from LP to BW and I keep looking for some very basic info like the differences and convenience of the desktop app (Win10) vs the browser extension (Chrome). Lacking a tutorial I can find that is a document, not a video, is what I desire so I can familiarize myself and know which directions to go without D/Ling stuff and playing around.

I’ll deal with the Android stuff later. I just want to get the desktop transitioned first.

TIA for any tutorial source pointers. I am not a CompSci guy but am a bit technical. On this pursuit I want to get on track with as little playing and experimenting as possible.