3 ms·
> It's not a misfeature, but a feature. It's inconvenient and unnecessary. I don't get what can be so hard about just giving the user the encryption key. In th
by thecodrr 5y ago
> It's not a misfeature, but a feature.
It's inconvenient and unnecessary. I don't get what can be so hard about just giving the user the encryption key. In the recovery flow you can just ask the user for the recovery key to decrypt the data and reset the password. That's how Notesnook does it. The email can never become a single point of failure like this.
- anaerobicover 5y agoIf there is another piece of data that can be used in the same way as the password (or to override/reset the password) then it is completely equivalent to the password itself from a security perspective. If you can lose the password, what prevents you losing both the password and this secondary key at the same time? If you store them in separate places, then just store two copies of the original password in those two places.
- thecodrr 5y agoWhat you say is right and that is how password managers work. However, human habit is that people generally keep their password in their heads. The point of giving a secondary key is that: 1. Since it is longer, the user is forced to store it in a file or some other place 2. The message behind "recovery key" is different to the "password" so users react different to it. Giving it more value and attention. 3. Encryption keys are still rare in clients so it stands out and the user again gives it more attention. With that said, it is entirely possible that the user won't save the key or lose it. In which case, nothing can be done. It isn't an ideal solution to account recovery problem but so far I have found this to be the only solution if you are going the zero-knowledge route.