Replies: 5 comments
-
Backup protected by a passphrase that the user doesn't regularly use is a great way to make sure they can't restore from it when they have to. Passphrase is most useful for export/backup protection.
I guess it depends on the user. I always use LUKS full-disk encryption on all my drives, so the encrypt-at-rest of the ID is needless for me personally, I guess. And all in all it's not all that interesting attack. I guess the biggest thread is some systemic attack, where a popular vulnerability is used to collected many unprotected IDs and then to introduce malicious dependency and hide it with fake reviews, etc. I guess one way to approach this is to create some temporary weak-ID, without a passphrase, mark it somehow as such and allow user to locally add trust proofs, and maybe even reviews, but definitely not publish anything. When the user is ready, |
Beta Was this translation helpful? Give feedback.
-
BTW. We could have a passphrase agent to help with having to enter the passphrase too often. It would listen on some local socket, and if not started |
Beta Was this translation helpful? Give feedback.
-
Currently the logic is this:
|
Beta Was this translation helpful? Give feedback.
-
On macOS I could use Keychain to either store the passphrase, or store the whole CrevID. |
Beta Was this translation helpful? Give feedback.
-
Yeah. On linuxes there are also some kind of keyrings (gnome, kde, possibly others). |
Beta Was this translation helpful? Give feedback.
-
For #384 it would be super convenient to create an implicit empty CrevID for new users, without a passphrse. What are the risks?
It wouldn't suggest backing up CrevID without a passphrase, and could require adding a passphrase at some point, e.g. before publishing anything. But how much are we worried about identity at rest on local disk?
Beta Was this translation helpful? Give feedback.
All reactions