Agree 100% here. I was very confused when I set up my 2FA key and this wasn’t happening by default! I now finally understand the whole difference between locking and logging out but this would still be very useful to have as a modifiable option, especially for those who often use their device in social settings.
3 Likes
Also noticed the same behavior. There is a thoughtful debate on the merits here; I can mostly see both sides, but feel that its a feature that makes sense to add (especially for web browsers).
Still nothing on this? My premium account and DUO account are literally useless.
Guys,
Can we get an idea if this is going to be implemented please? We need to move to a different platform if this is not on the radar. We need it to lock and ask for 2fa each and every time.
1 Like
Another vote for implementing this. I’m a recent convert from LastPass and was shocked to see after getting a premium account that 2FA is rendered “useless”. Great, so it works when initially logging into your vault, but from that point on it’s never used again.
There absolutely needs to be an option (which can be set to off by default to retain “user friendliness”) that lets you log out of your vault when you close the browser instead of just locking the vault.
Seems to me that’s a no-brainer and would be straightforward to develop. I’m not sure why that was never offered as an option.
What might be more complicated is to force the use of 2FA on unlocking the vault. But if we can just get some sort of auto-logout option on browser close (as well as auto-logout after X time), I think a large security gap would be closed.
1 Like
Auto-logout setting would be the ONLY way to implement this.
When in a locked state, there is enough information on your computer to brute force your password without talking to the server. Logging out wipes that data.
Having a “2FA for Unlock” is security theater and someone will think they’re safe when they’re not.
Does anyone know an alternative system which simply provides “auto logout” as an option for those of us who need it?
Agreed. Still waiting on this functionality but can’t wait forever. At some point I will have to look at other PMs if we don’t even have an indication of a roadmap.
1 Like
Thoughts on 2FA for sync with a TTL? You can still operate with a “read-only” local copy. But if a Delta is found between the local copy and remote you must 2FA. Being able to update / pull a new DB copy after simply unlocking seems like an elevated privilege and IMO is where 2FA can be impactful.
Either way I don’t see much benefit with premium 2FA given the current 2FA approach.
(The manual workaround could be to log into the vault and stop all sessions from the settings page. Definitely not ideal, I did not see that setting for an organization either. Which is what I’d really want)
The reason why 2FA hasn’t been implemented for unlocking of the password store is the fact that it has to work offline.
U2F, TOTP, SMS/call verification and some other methods require a trusted server on the other side. This is not possible with offline stored data.
KeePass tries to solve it using challenge-response but it changes challenge only after database change, not after every unlock (and previous versions would still use the previous challenge).
I guess that since every device is different and doesn’t offer the same hardware security options, it’s not that easy to tackle this.
Even if automatic logout was introduced, it wouldn’t change the fact that password store has only a password, and 2FA would only prevent getting a newer version from the server.
I guess it is probably fine to have the offline password store secured with just a single factor (password, fingerprint or maybe something else that is backed by hardware) but don’t store the TOTP seeds in that database because it effectively becomes a single factor auth if that data store and password for it is lost.
This thread lasts since March 2018 now and the only comment we get from the staff is, that this is similar to Auto-logout after X minutes in March 2018, or did I missed something?
For me to become a premium this auto-logout is a must and unlocking without 2FA makes no real sense for me. If offline then single-factor authentication is sufficient for me since this the user’s responsibility to chose an adequate password. And the Idea of logging out and deleting the data is a design choice I still cannot really follow. 2FA should only be applicable if online.
Since both threads, this one and the auto-logout thread, last since March 2018 and also since people are still engaging to get those features implemented (as myself of course) can we expect some statement from the Devs if one intends to implement those and eventually when they will hit a theater near us?
It seems that to know that (also for me) could motivate some of us to get a premium account 
I hardly see the problem of having the 2FA provide local and offline authentification. There is a reason Yubikey and other provides so many protocols.
Use the OTP and U2F for login and data update.
Use HMAC-SHA1 Challenge-Response for unlock, like for computer login.
As for debating why and when to have 2FA, it seems easy to forget that a “trusted device” should never be permanently trusted. We don’t how after how much time a session expire either, so it should be better to assume that you need your 2FA checked up every once in a while. Maybe every 15 mins, maybe everyday, at least every week/month…
1 Like
@m0ll3art, you are mixing things up.
“Unlocking” is the offline action that is done on the client side after data has been downloaded. This can not really require 2FA in any way.
“Logging in” is the online action that downloads the encrypted store locally. This can already require 2FA if it is enabled.
Introducing automatic logout and removal of local store copy would not really solve many problems because at the end of the day it all comes down to trust that your live system and server is not compromised.
If your computer is owned, they get all of the credentials by waiting for you to unlock the database once, even if you use 2FA. Current password stores protect you in case you loose your laptop or something like that.
If server gets owned - attacker can wait for you to log in and get the credentials for the store. (KeePass password stores in DropBox are potentially more secure because Dropbox password can differ from the KeePass password. With Bitwarden they are the same.)
Then of course there are also organization credentials which have to be shared and thus key to them has to be stored on the server as well. So in this case attacker wouldn’t even have to wait for user to log in.
And believing that locking the database removes master password from memory everywhere is just a wishful thinking. In reality it is stored in multiple places, most of them out of reach by the developer of the software, especially in case of browser based tools like Bitwarden is.
Here is a nice article about it: https://www.securityevaluators.com/casestudies/password-manager-hacking/ They didn’t test Bitwarden but it is probably in an even worse position due to being built using web tools.
Windows, Linux, macOS, iOS, Android and major browsers usually get serious vulnerabilities discovered multiple times a year. The ones seen in wild get patched quite fast though. So far we haven’t seen many global campaigns that use these vulnerabilities in very advanced way and the last major ones were probably the extorting crypto viruses. But if an advanced actor targets you or your organization specifically, you probably won’t be able to successfully defend against it and the current generation of password managers won’t be sufficient.
For serious things if you want better security, use hardware backed credential stores and hardware 2FA like Yubikey (but even those can’t be 100% trusted). You can store limited TOTP entries on it and you can never get the seed out of it, only the calculated value. Hopefully in time Apple and others will improve their hardware and SDK to allow storing more kinds of secrets in their secure element but currently I don’t think they are mature enough.
So don’t store the most mission critical data and TOTP seeds in Bitwarden and you should be good enough.
@Janhouse not quite sure about that… but it’s your call.
To be online or offline (connected to network or not for me) has nothing to do with unlocking or logging out. By logging out, Bitwarden is deleting the local pasword DB, by unlocking it only locks the access, and this has nothing to do with 2FA or not, since 2FA is only an authentication security mechanism and could be applied in both cases. Its purely a design decision
Now what is more disturbing and which I just experienced is that the Bitwarden seems not to be connected together between browser extension, desktop and remote copy on bitwarden servers
I just wanted to use the auto-fill login for this forum and my desktop app was unlocked but the extension claims that the vault was locked. So I had to unlock Bitwarden browser extension Vault to trigger the auto-fill function, despite the fact that the desktop app was unlocked. The same is true with creating a new login item I had to trigger the synchronisation manually to get the new login item visible in the desktop app and that is for me a real no go. Perhaps I missed something here …
The security issue is more related to
The ones seen in wild get patched quite fast though
since Bitwarden relies mainly on one to a very few Soft Dev(s), I’m not sure how fast breachescan be fixed. And this is of course not an offense to the Devs in no way, since it is completely clear that they cannot fight on all front at the time.
And imao I’m not too much concerned with a local attacker or remote ones since hosted on Azure infrastructure and those guys know how to protect their infrastructure, but more with the fact that
Bitwarden operates under the “exclusive jurisdiction and venue of the courts located in the City and County of Jacksonville, Florida.” ( ProPrivacy.com)
which for an EU citizen is more of concern… Azure committed to GPDR but still, the Jurisdiction dominates the debate
Sorry, it seems that I was too technical but what I said still stands.
Doing “login” procedure does equivalent to logging on a Dropbox and downloading encrypted file.
Unlocking is just unlocking this downloaded file.
You can not add 2FA to a downloaded file because there is nothing to do the procedure against. There is no server involved to verify. The only thing you have left to do is decrypt.
Clients should not be “connected” together in a way you described. Each client is separate instance that has no connection to one another, only to the server to synchronize changes. Adding additional interfaces between clients would only introduce additional attack surface.
Bitwarden servers are probably better secured than casual users laptop so I would not worry about them as much. And I am personally interested only in the self hosted option of Bitwarden.
With your comments in mind, I would certainly trade offline access for a functioning 2FA feature (for both login and unlock). I can’t think of a single instance I needed a password where I was not online, and I don’t care if it is accomplished through an auto-logout feature or otherwise. It could even be an “Advanced” feature where you get a warning about no offline support when enabled.
You don’t really gain much additional security for already downloaded password store by adding 2FA. Unless passwords were returned one by one from the server, and each individual password request asked for 2FA. That would then be a totally different product.
I am not sure I follow. Requiring something you know (your password) and something you have (Yubico OTP for instance) seems a lot more secure than just something you know. With a security key like YubiKey even if someone across the world gains access to my device, they would still need the second factor to login. There really isnt the ability to brute for it at that point, no?
1 Like
I agree with @ksnell and this what I tried to explain, but perhaps we are way not enough technical 
Unlocking, logging out and the fact that the password “DB” is deleted with each logout is a design decision and not a technical issue (i.e. 2FA is not needed/possible because unlocking only operate on a downloaded file ) and a lot is mixed in the last comments. 2FA is possible technically also for unlocking, this can be implemented, now if it makes sense from a design point of view is completely different (only for the case were unlocking = no internet then the answer is straightforward).
The problem is also what is Bitwarden doing when in locked state? Are the master password and accessed/all passwords obfuscated or scrubbed? etc…
Clients should not be “connected” together in a way you described.
yes they should otherwise I do not need a password manager to sync my password between devices, and this is why I gave up to try Lastpass since between the firefox extension and the chrome webapp (deskop app should be rewritten imao, same is true for Bitwarden on macos at least) the sync was not done, I had to wait for minutes (>10) to see the sync happening. Same test with bitwarden = instanteneous…
Agreed. Ultimately, I don’t have the expertise which is why I pay for Premium to help fund development. It is up to the developers and their expertise to implement the feature (which I don’t think is a huge ask considering it is already half implemented). People use password managers to be secure and this is an extra security layer that is becoming more and more common these days.