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.

You can try https://www.heylogin.com if you are looking for a new approach without a Master Password. I am one of the founders.

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.

This is a wake up to call to not build your security model on a user chosen master password!

Since the vaults have been stolen, an offline brute force attack can be executed. This attack is no longer slowed down by online protection mechanisms, such as blocking IP addresses. Rather, security now depends solely on the cryptography and thus on the master password chosen by the user.

In the end, it is a single factor that separates the attacker from the encrypted data. If less IT-savvy employees are not adequately trained and supported in choosing the master password, the result is fatal. The extent of this will become clear in the coming months when the attacker has cracked the first master passwords and compromises accounts.

At heylogin, we believe that this security model of traditional password managers has come to an end. That's why we built a new solution that uses the secure element of smartphones to implement end-to-end encryption that is 2-factor secure by default and works without a master password.If our users' encrypted databases were stolen, the attacker would not be able to perform a brute force attack.

I just wrote a post on our company blog about the problems of LastPass and how to fix these: https://www.heylogin.com/en-post/lastpass-incident-2022

Yep, Nextcloud is using our SDK from https://hwsecurity.dev/. We provide dual licensing for closed source and GPLv3 projects.

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.

We developed a vendor-independent FIDO U2F implementation for Android that works with Security Keys over NFC and USB.

It's dual licensed under GPLv3 so you can inspect the source code or use it in your open source Android app: https://github.com/cotechde/hwsecurity

I came to a similar conclusion: U2F hardware is the way to go. For some people, smartphones are becoming the only device they use. However, I am not fully convinced of using the device itself as a U2F key. Then it's no longer a two-factor solution. Thus, I envision the use of U2F hardware with mobile devices as the future of authentication.

Unfortunately, it is still difficult to find the NFC "sweetspot" at the back of your phone. At Cotech, we work on a Hardware Security SDK that solves this and works independent of Google Play Services. It brings support for U2F Hardware over NFC and USB to Android phones: https://hwsecurity.dev/fido/

On Android, we provide the OpenPGP implementation OpenKeychain that now also supports an impressive list of Security Tokens (https://github.com/open-keychain/open-keychain/wiki/Security...). In our newest release, we also support YubiKey 4 over USB-C, which is a great alternative to NFC (which is only support by YubiKey NEO).

Regarding SSH: We submitted a pull request to ConnectBot. You can try it out if you like: https://github.com/connectbot/connectbot/pull/567

Author of the paper here.

Yup, in regards to Signal our findings are already obsolete :D I think that the new Signal developments are great. It is better to allow only one key verification mechanism for unified usability and also use key continuity. Before, SAS needed to be verified for each call again.

Author of the paper here.

There is existing work on testing the feasibility of impersonating other person's voice. We discuss them in our related work section at the end of the paper.

I think on the long run, SAS will no longer be a sufficient authentication technique due to advances in speech synthesis. To prolong ZRTP's life we propose usage of sentences instead of words/chars. This is discussed in detail in our best practices section.

Yup, we are working on the remaining points, see https://www.openkeychain.org/k-9/

- Dominik

OpenKeychain developer here. If you have any questions about certain fixed vulnerabilities or features, I am happy to answer any questions.

If you are on Android, use OpenKeychain. We don't ask these questions. Instead, we have a simple wizard guiding you through the process of creating a key. We don't ask for the algorithms (RSA, DSA,...). We don't ask for User IDs. We don't mention the words private or public key.

See http://www.openkeychain.org/