[sufficient]

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.

[wkdneidbwf]

> 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.

you can bootstrap from an existing installation too. you’re painting this to be more of a hassle than it actually is in practice.

[sufficient]

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.

[paulryanrogers]

What does migration look like for a new device?

If a phone is lost and it's TPM compromised would that put all future credentials at risk?

Most of the derived ideas strike me foolish since they compromise future and past. And they accrue state anyway once one must rotate keys.

[sufficient]

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?

[mdaniel]

> since the e2ee does not depend on a user chosen master password.

What's the story with "my phone went in the lake" using that setup?

[isthisthingon99]

Since i use Google Authenticator for numerous services this is going to happen to me one day. So what I did was set it up on more than one phone.

[mdaniel]

I would legit pay money for Google to pull that piece of junk from the Play Store, because it's damn malpractice at this point, given there are so many other options that don't straight-up swallow the TOTP keys

[isthisthingon99]

Sorry what

[FreakLegion]

You can back the secrets up to a text file, print them out, etc. too. They're short Base32 strings and TOTP is a standardized protocol with an RFC (6238) and everything.

[jve]

Except it is cumbersome to doo on Google Authenticator. You must press export to get shown a giant QR code. You can't screenshot it. Must photo with different phone and print on a piece of paper for offline storage.

[isthisthingon99]

Yes i did this too

[ThrowawayTestr]

I also have two phones with Google Authenticator. Is that a bad idea?

[sufficient]

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

[8n4vidtmkvmk]

fish it out of the lake and pay someone $1000 to extract the tpm and restore it for you