sufficient

Thanks, that's interesting. We don't see all the smaller changes our competitors are doing. With heylogin, you could try our Quick Access feature. It pops up with a global shortcut and is fully keyboard navigable. Let me know if something is missing there.

passkey support is currently in internal beta, but will be released soon. what kind of features have been removed from 1pw that you considered important?

Hey, CEO and Co-Founder of heylogin here.

Feel free to try out heylogin and let me what you think of it. I know we don't have feature parity with 1pw, but we try to innovate on the core user experience of logging into websites first. Our typical users are non-IT people, but more and more features are now implemented to also cater IT pros.

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.

Just wrote a longer answer to the question below, hope that covers your question as well.

You are asking the right & also complicated questions :)

Let me first say that we are just finishing up a version 2 of our whitepaper that can answer all questions regarding the cryptographic architecture including these scenarios. We'll announce that in the next 2-4 weeks when it's ready.

There are different scenarios here:

* If you install heylogin on a new phone, you will get asked to transfer your account to the new one. If you confirm, everything is cleared on the old phone, secrets are regenerated and date is re-encrypted.

* If you are using the team features of heylogin, your admin can disable your old phone (even if it's broken) and you can connect a new one with the help of the admin. The secrets are re-generated and data is re-encrypted. The underlying architecture is a little bit more difficult here and will be explained in the whitepaper.

* You can write down a backup code and use this for recovery (I like this method the least)

* We'll soon have a feature where you can add a security key as another method of accessing your data. This will also help in re-gaining access if the phone is lost.

* We'll also probably have a "social recovery" in the future, similar to the admin recovery flow but for private users.

Internally, we have more ideas to provide transfer & recovery flows. We'll keep on experimenting.

Since secrets are re-generated and data is re-encrypted, even if the old phone is broken, the TMP no longer holds secrets that are usable to decrypt the data.

Does this answer your question?

maybe… I sort of agree it's not a huge hassle when recovering from another still functional 1Password installation. I still think that the initial flow of asking the user to print something that looks complicated is something that turns away users who are less IT-savvy.

I think we can do better in protecting vaults against offline brute force attacks.

As written in the this post, 1Password uses a randomly generated "secret key" together with the user-chosen master password. This "secret key" is not stored on 1Password's servers, instead it should be printed on a piece of paper and stored safely. While this is a good starting point, it significantly reduces usability, since you need this piece of paper when re-installing 1Password.

At heylogin, we are rethinking this cryptographic design. In our case, a random secret is generated inside the smartphone's security chip. From this secret, all keys for encryption are derived. The smartphone app and the browser extension is end-to-end encrypted and authenticated using an out-of-band QR code. This results in the following UX: To log into a website in the browser, the user needs to confirm on the phone. The app now provides the extension with temporary access to the passwords etc (a little bit more complicated to explain here).

Thus, if the same breach would happen to us, the vaults would still be secure, since the e2ee does not depend on a user chosen master password.

It's not easy to get a foot in this market, but I am confident, we can do it.

Great work Fabian! Nice to see this work becoming open source.

I am pretty new to fuzzing, please correct me if I am wrong: Since Jazzer fuzzes a Java application at runtime, can it be in principle also be used to fuzz a Java app without having it's source code?

I agree that it's weird that they fixed it and didn't consider it a security issue.

For the user it looked like it would provide two-factor authentication since the PIN is requested, while in reality it's not verified. Thus, they only provided one-factor security.