(no title)
sufficient | 3 years ago
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|3 years ago
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|3 years ago
paulryanrogers|3 years ago
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|3 years ago
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|3 years ago
What's the story with "my phone went in the lake" using that setup?
isthisthingon99|3 years ago
sufficient|3 years ago
8n4vidtmkvmk|3 years ago