Why do you say that? That just acquired passwordless.dev, have passkey support on their 2023 development roadmap, and are members of the FIDO alliance developing passkey standards.
Sorry, I wasnât clear on that. I meant replacing the master password with passkeys like 1P plans
Sorry for the confusion
Got it. They havenât formally announced this. But, they are very active in this passkey space with the acquisition, roadmap, and FIDO Alliance membership.
By the way, if you look at the 1Password demo solution, it appears they are using Appleâs passkey implementation. I bet thatâs how they go live with this by summer, which any password manager could do. However, when you click on the other link, the longer video shows a demo of integrated passkey support in the 1PW product, with some not so subtle lobbying about the importance of having open standards that companies other than GoogleM$Apple can utilize this so we can all own our own passkeys rather than having them locked in one of those three walled gardens. This is the real fight and itâs far from resolved. I have been playing with Appleâs passkey implementation on sites like eBay. Itâs seamless and easy to set up, suggesting to me that the tipping point to mass adoption may be earlier in the cycle than we anticipate. Now try and export your own passkey. You canât. Only currently works with Airdrop. And the big players are reluctant to open it up as they argue itâs an attack vector (can you imagine all your passkeys stolen and in the wild). We need to own our own passkeys and so voices like 1Password and Bitwarden at the FIDO Alliance table are critical.
4 Likes
Thanks for your reply.
Thatâs indeed something which caught my eye - therefore I asked them directly: From launch on, they will also support Yubikeys (or to phrase it better: they support the whole FIDO2 standard).
Thatâs what I always wanted from a password manager. Plug your thingy in, enter the PIN (or biometrics) and off you go.
While Appleâs and Googleâs own implementation is not platform independent, FIDO2 sure is (and you can use multiple keys if you want, one passkey from Appleâs ecosystem and etc., although thatâs not ideal ofc).
I currently donât use passkeys at all. Why? Because Iâd have to enable iCloud Keychain on my devices - which Iâm not going to do anytime soon (in fact, Iâve gone to great length that Appleâs HSMs delete my device passcode, but thatâs another story)
Therefore Iâm hoping BW will accept storing passkeys soon.
3 Likes
Exactly same with me. I enabled keychain to try passkeys then disabled it. I also need to boot up an Android device and try Googleâs implementation. I will never try the M$ implementation (did I just age myself?). 1PW hasnât announced when they will allow storing of other keys. The longer demo video shows what it would look like and drops in some lobbying. So, I think it will be awhile until password managers can do this and then Bitwarden and 1Password will implement at similar times. The competitive disadvantage to resting on your laurels doesnât compute and they are both very active in this space. All good things to come, I think.
2 Likes
Iâm really looking forward to this. This solves a thorn for me with a hardware key like yubikey, I donât want to have to carry an additional item on me; whereas a phone is always on you (for me/most people).
You can make your phone your passkey now. Google allows this. Try it. It makes me nervous to have my phone - which I will one day lose or have stolen on vacation - as my passkey. This is partly why I want to be able to store my passkeys in Bitwarden so they are not device or platform dependent.
I did it already using an iPhone and worked well but had to terminate it, since I regularly login at work using the extension. I would get the pop in a usb key or choose another method. This just slowed me down and I am waiting for integration to mature more where the phone can be used to authenticate a computer login.
Thatâs why it would be nice if this can all be managed thru bitwarden. Have a list of devices as your passkey, if one is lost stolen etc login from another trusted device and remove the lost phone.
2 Likes
I can see this feature has been respected for about 4 years at least.
Confused why Bitwarden donât implement it.
For me its an additional 2FA that would let me trust a cloud service more than at present.
1Password can do it. Keepass can do it. Bitwarden needs to catch up.
Iâm surprised that Bitwarden team is ignoring this feature. It makes 1password more reliable in terms of account security and this is my main concern when deciding which tool I want to use. And it would also affect my family as Iâd like to convince them to start using password manager. The main reason is that here, the only security is a single password, if somebody knows this single password - will have the full access of all my data. I know - I could add the 2FA, but itâs not easy to convince all my family to use 2FA. Itâs definitely less convenient than one-time setup with the Security Key. What is great with Security Key is that it protects the user from Phishing attacks and Keylogger. I trust your encryption, connection security, etc. but Iâm really not happy that my account is protected by default just by one phrase - this is the main Advantage of having security Key, itâs more convenient than 2FA and actually makes my account much more difficult to hack with the most common remote hacking methods (mentioned Phishing and Keylogger).
There was no clear explanation on why this cannot be done.
Iâd think amount of effort is too large for a small benefit (as perceived by development team). Itâs also possible that Bitwarden architecture has some serious incompatibility with split secret mechanism, but i doubt it; other comparable systems provide it; both server and clients would sure require update.
I sure do disagree about size of benefit though; lack of split-secret and reliance on a single passphrase it is why many security conscious organizations chose to avoid Bitwarden. Itâs unfortunate that authors do not see is as important, but it creates diversity in the marketplace, otherwise all password managers would have same feature sets.
âigor
It hasnât been mentioned and this is my personal guess, so take it lightly:
If you look at Bitwarded Security Whitepaper, at the Login diagram that shows whatâs on the client side and whatâs on the server side, you will notice that the âProtected Symmetric Keyâ is stored on the Bitwarden servers (encrypted). Whatâs asked here (and AFAIK what 1Password does) is for that key not to be stored on the server-side at all, or to have a second symmetric-key component for the encryption. That would be a fundamental architectural change for BitWarden because itâd be a different security model.
Itâs this diagram:
There may be some middle ground where the Master Password (+email) is accompanied by a second client-side secret stored on the app/device/browser, that would also feed into the master password hash. But that would then open a separate discussion about why BitWarden needs to hold the Protected Symmetric Key at all.
So as far as I understand the reason this isnât being considered is that itâd need a different security model, potentially for little benefit since many people already consider BitWarden secure enough. If the latter changes then thatâd be an incentive. IMO even doing the middle ground could help, but discussing it would start this discussion from scratch. Good enough is a reasonable approach and there are good points on both sides.
Again, this is my personal guess.
Thatâs not really what is being asked in this feature request, and it is certainly not what is done by 1Password.
The disadvantages of the secret key model is that it increases the risk of locking yourself out from your account, it places barriers to accessing your account from a new device, and it offers no protection against attacks on usersâ devices, all for a security benefit that only applies to users who choose a weak vault password.
Instead uses Bitwarden a Data Protection Key that is independently secured in a tightly controlled Key Management Service using hardware security modules to protect the keys (i.e., these keys do not exist on the cloud servers that house the vault database). The Data Protection Key is used with AES-256 encryption to add a second layer of encryption to your Protected Symmetric Key (the scrambled version of the account encryption key, which is AES-encrypted using a stretched master key derived from you master password). This approach is, in my opinion, superior to a âsecret keyâ type approach, because it is transparent to the user (it does not require special authorization procedures to commission new devices, and it doesnât increase your lock-out risk).
If you want to educate yourself about Bitwardenâs security model, feel free to start a thread in the Ask the Community section of the forum.
Citation very much needed. It actually is, at least for what matters. Indeed the keyset is stored on the server-side but its decryption happens on the client. The server-side never gets any hashed version (or the raw) of the secret key and thus of the MUK. The keyset being stored on the server-side isnât much different than the vault because they are both equally well encrypted so if one were to break the keysetâs encryption then they may as well break the vaultâs encryption.
Well, yes. By definition thatâs whatâs being discussed here. If you can unlock yourself from your account easily then someone else can do that too.
Sure. You need to transfer the secret key using an OOB method or have another device online. Again, not relying solely on your password is whatâs being discussed here. If someone feels brave there could in theory be a version with an empty secret key so that they only rely on their master password. But that would be terrible security for that model.
It protects against keylogging, screen capturing (with on-screen keyboard), plain eyes, a camera, and more. It also makes it clear that you donât need to memorize and type a strong password. The password becomes a pin. Things gets more complicated (and better) with an on-device security chip that can directly or indirectly protect the secret key.
Yes. That has been said before. BitWarden is best for users that can be trusted to have a secure password and use it securely. Less for the average user with a weak password.
And yes, it isnât that cut&dry and the use of 2FA helps a lot with weak passwords. And so do on-device biometrics.
I think that my explanation about the reason BW doesnât support a secret key is plausible. Iâm not going to ask in a different place because I wasnât the one asking the question in the first place. Noone else, even now, including you, bothered to answer that question.
p.s. I get the feeling that thereâs a drive towards confrontation and defensiveness in this thread instead of focusing on plain facts. You could have very well responded to siaâs question instead of waiting 5d and then post an âif you want to educate yourselfâŚâ reply to my reply. Thatâs not great.
The same is true in Bitwarden.
You said that the protected (encrypted) key should not be stored on the server and claimed that 1PW does not do this. Yet at the top of page 40 of the whitepaper you linked, they state that âafter successful authentication, the client can request its encrypted
personal key set from the server.â
The same is true in Bitwarden.
Bitwarden uses multifactor encryption with four layers of encryption, only one of which relies on your master password.
So does 2FA.
Thatâs dangerous advice, and if you dig into it, youâll find that this is not 1Passwordâs position on the matter.
You can get the same benefits using Bitwardenâs options for unlocking with a PIN or biometrics. To borrow your turn of phrase: the master password becomes a secret key.
So we agree on some things.
I have no affiliation with Bitwarden and no insight into their decision making process. I can only offer my speculations, which Iâve done in my response above.
I only wish to confront inaccurate information, so that forum readers are not misled. The tone and content of your earlier post made me think that you were in the process of learning how Bitwarden works but hadnât quite figured it out yet. My response was intended to set the record straight and to offer you an opportunity to learn more (in a forum more suitable for such purposes). The offer stands. 
I wish 2FA can be used as a one-time App setup. Thatâs because itâs really not so convenient to constantly using real 2FA - itâs great for services that keeps you logged in for a while (like google account), but not for services that I need to login constantly many times a day on a different devices, and this is the great point of having the secret key that is required only when setting a new device.
So the main point is the convenience but with keeping better security than relying just on a single phrase that you are constantly entering, every day, so itâs a really easy phishing attack vector. I know that itâs easy to request improvements and often itâs difficult to implement them. Just please, keep in mind why we are asking about those - this is about better convenience vs security, while in other platform we can have both of them, here we have to choose. And for many people User Experience is really important factor, I donât want to be distracted many times a day for doing the long login process during my work on my PC (in case of having 2FA with like mobile confirmation or Auth Codes), or with an USB device - I would have it plugged all time which is OK but breaks the experience when I want to use Password Manager on Smartphone - this is exactly why Secret Key is a good balance between security and convenience in many cases.
PS. The âpin codeâ feature is a fair point in this conversation, I will also check the Windows Hello with a fingerprint unlock. So I personally will give it a shot. In mobile device we have a fingerprint unlock which is also great, so maybe it will be enough.
The way that Bitwarden is normally used (with Vault Timeout Action set to âLockâ), Bitwarden will remain logged in practically forever (unless there is a server-side event that deauthorizes your login session, which happens very rarely, or you leave the app/extension unused for more than 30 days).
If you mean that you create convenience by using a weak vault password, then you are still trading off security.
1 Like
Great discussion, folks. Closing this topic as there are no plans to implement this, given that all new accounts are created with 600k KDF iterations, Argon2 is another encryption option, and multifactor encryption is an additional layer of protection for the encrypted data at the server-level that doesnât add any user overhead to manage.