Add (optional) Secret Key functionality (Like 1Password) or keyfile (Like Keepass)

It would create security benefits for the cloud vault similar to what is achieved in 1Password with the secret key, but it is transparent to the user (i.e., there is no requirement for the user to store a secret key on each device). It will be applied automatically to all cloud vaults upon access. I’ll defer further commentary on this new feature until the revised whitepaper has been released.

P.S. @222 They are re-encrypting both the master password hash and the protected key. This shuts down the ability to by-pass server-side KDF iterations, that everybody was panicking about in January. :roll_eyes:

2 Likes

Thanks for clarifying, @grb !

1 Like

I wonder if this debate becomes moot when Bitwarden introduces passwordless sign this year. @bw-admin Do you or any other Bitwarden folks have any information about how it will be implemented and if we will be able to get rid of the master password in place of a WebAuthn passwordless sign on? Or, if we will always need a master password as a fallback? Very curious how this will impact Bitwarden’s security model.

1 Like

I don’t think that’s possible yet. WebAuthn doesn’t share a secret with the server you could use to encrypt stuff.

Edit: Sorry, I forgot to add that IMO they just find new ways to log in by confirmation from an already registered app. („IP“ wants to log into Web. Do you want to proceed? or something like that.)

Thanks for the continued discussion all, there are multiple security initiatives underway as the team is always making improvements with the changing landscape, see Data protection for user columns at rest by kspearrin · Pull Request #2571 · bitwarden/server · GitHub as an example.

I don’t think so. You needn’t be worried, we will still be able to continue and enjoy this thread. :laughing:

Are you thinking about the “Passwordless Login Options” on the roadmap?
I have always thought this refers to the “Log in with device” option (currently only on the web vault) getting extended to more client types. I think we will still have a master password and an account encryption key derived from this password.

I think the “Passkey Support” is all about building a FIDO2 roaming authenticator into BW so BW can store passkeys from other sites (like it does for passwords at the moment) and not about logging in to BW.

1 Like

No doubt. LOL!

I am referring to the passwordless.dev acquisition and passkey support. I had assumed, perhaps incorrectly, that if Bitwarden is introducing passkeys for other sites, similar to GoogleM$Apple, that they would also do it for BW. Only makes sense to me that they wouldn’t exclude themselves from that new form of protection.

Although I like the idea, I have no clue how to implement that.

Even if you don’t like to safeguard the safety kit, I do hope you have your BW master password stored somewhere. If not, there’s a good chance that you’ll forget it and lose access to your account at some point.

1Password secret key implementation is actually very convenient especially for Apple users as the secret key gets automatically backed up and synchronized transparently to all your Apple devices (iPhones, iPads, Macs) through iCloud Keychain. So, you don’t need to worry about it after you have set it up for the first time. Same with Android devices. Linux/Windows of course lack similar functionality, so you need to do it manually if you’re a PC user.

This is a bold statement. Server-side encryption and key management are difficult (and pricey) to do right. Even if done by the book, i.e. for example using HSM for cryptographic operations and key storage, as a Bitwarden user you would still need to rely on their opsec implementation. One misconfiguration or vulnerability in a critical component could lead to exposure of all user data. There’s a reason why both Apple and even Google to some extent are moving from server-side encryption towards E2EE.

The examples you outlined - Apple and Google - both use THEIR HSM for e2ee.

I doubt that.

1 Like

Believe me, I know everything about iOS and macOS security. Before you doubt stuff read the source you linked carefully.

Hint: Keychain Escrow service

Edit: Sorry, I didn‘t want to be impolite. It just took me a while to find the stuff out myself (I read the whole platform security guide, that‘s 200 sites of highly technical stuff. And it annoys myself that I‘ve done that to myself ;))

I believe I know a thing or two about that topic too. Unless you provide a link to a document that specifically says that apple has access to your encryption keys when using e2ee, this conversation has no relevance to the topic.

I‘ve edited my comment. This document.

Oh, I‘ve never mentioned that they have access to the keys.

Sorry, I thought you meant that as Apple is using HSMs, they have access to the encryption keys but if this is not the case, we are pretty much aligned here.

The HSM. do have the encryption keys, the HSM‘s firmware is not updatable and therefore - in theory - Apple hast lost access to them once they firsg booted up

Edit: Those HSM also store your device passcode

Is this the document you intended to link https://help.apple.com/pdf/security/en_GB/apple-platform-security-guide-b.pdf

They always deny it but I think Apple must have the keys. (p130)

I first became suspicious of Apples E2EE when I enroled a new iPhone into my iCloud account with all my other devices switched off.
I thought “how have I got a full copy of my keychain when Apple say they don’t have the keys?”

1 Like

Whoops, I‘m stupid. Thanks for linking it though.

2 Likes

Not intending to stir a hornet’s nest, but it looks like 1Password has subtlety kinda-announced it is phasing out its Secret Key security model.

https://blog.1password.com/unlock-1password-with-passkeys/

Video is also pretty good and is clear that they see passkeys as their future. This will take years to phase in, of course, no different than everything else on the internet. But, this is the first time I have seen them start to signal they are moving away from their Secret Key security model, which, of course, is unnecessary in a passkey world, as 2FA will also be unnecessary.

I‘d like that approach too, but I doubt Bitwarden will do anything in that direction in the foreseeable future.