Add trusted device verification - #7034
Conversation
|
I'd like to work on an open source version of the key connector (making it from scratch basically), but I have a crucial question before I start. Do you guys think this should be an external service/container, or does it make more sense to build it into VW? My goal is to have SSO only logins, while only prompting the user for a master password during account creation. |
I would suggest to read the comments posted here: #6949 In my opinion, Key Connector shouldn't be something supported by Vaultwarden. The chances of having security issues in either Vaultwarden or the custom Key Connector are always possible and makes the whole logic keeping everything safe and encrypted almost nill. |
Hmmm, I see. I totally agree with the security implications. My main use case is to have "something of value", so I can have better arguments while convincing friends and family to switch from cloud based password managers. As you already know, those "just work", and nobody cares to enter a password these days, let alone be forced to do so on every log in. This is why I consider my local only VW instance, even with a "potentially vulnerable" key-connector, to still be a better option, while literally being a better option user-flow wise (Paired with PocketID in my case, which is passkeys only, so it can't get more idiot proof than that). Now, regarding my security (and the security of other like-minded folks out there), the idea was to have a per user toggle, which would allow/deny key connector usage for that account - making the whole thing optional, while being a cool feature nevertheless. I'm sure I wouldn't use the key connector for my main VW account, but for the phone account, friends, family - it just makes sense. And of course a global env var would be required to turn on the feature at all. Either way, architecture wise, I'm leaning towards keeping the key connector in a separate container / as a separate service. My main dilemma is that the per-user config toggle would likely require modifying the settings page, and since I want this change to be upstreamable, I know UI patches create potential maintenance problems down the road, so I still haven't figured out if that toggle (or an entire custom user settings page, if there's more than one setting we'd like to control) should be separate from the original BW web vault, or if I could just patch it in there. |
|
Hey, Tested changing the activation condition to require only that the account already has a masterPassword which make using the feature possible without having to setup an Organization.
|
| }; | ||
|
|
||
| json!({ | ||
| "HasAdminApproval": has_admin_approval, |
There was a problem hiding this comment.
Should probably always be false since it's missing the logic to handle admin approval.
|
Hopefully either this or the derivative PR make it in. This would be a great feature for everyone. |
5 participants
This kind of sucks. I was hoping to make it work so the whole thing is idiot proof.
I guess friends and family will still have to type their master password at least once, and will still have to remember some sort of pin at the very least, for unlocking the extension, but at least this eliminates the need for typing the master password multiple times during new device registration for example.