Goldberg's answer "The 1Password Secret Key may not be the most user-friendly aspect of our human-centered design..." is unfortunately true.
We experienced a lack of understanding on the user side that this secret key needs to be printed and stored safely. It feels like a huge barrier for the adoption of 1Password for non-IT affine people.
This and other challenges led us to develop heylogin which does not require a master password and has no secret key that needs to be printed. Instead we generate cryptographic keys using the user's smartphone. For providing your desktop browser temporary access to passwords you simply confirm on your smartphone. This feels similar to modern SSO solutions but is technically a password manager.
In our experience, a user with one phone doesn't really need this key. You'll always be able to log from that phone into that phone's vault with just the password.
It's only if you're adding another device or logging in online, or replacing a lost first device with no backup, that you need the 2nd piece of key material.
Secret keys are backed up in order to recover the data in the event of device loss, and master passwords are used to prevent data access by an attacker with disk access, including access to device backups in the cloud. Am I misunderstanding, or are you just accepting that the data gets lost or breached in those situations?
We experienced a lack of understanding on the user side that this secret key needs to be printed and stored safely. It feels like a huge barrier for the adoption of 1Password for non-IT affine people.
This and other challenges led us to develop heylogin which does not require a master password and has no secret key that needs to be printed. Instead we generate cryptographic keys using the user's smartphone. For providing your desktop browser temporary access to passwords you simply confirm on your smartphone. This feels similar to modern SSO solutions but is technically a password manager.