Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to never show the seed again #861

Closed
chevdor opened this issue Oct 26, 2021 · 5 comments
Closed

Add option to never show the seed again #861

chevdor opened this issue Oct 26, 2021 · 5 comments

Comments

@chevdor
Copy link
Contributor

chevdor commented Oct 26, 2021

The display of the seed is fortunately logged.

A step toward an even more strict security would be the ability to setup a flag (not modifiable afterwards) signalling that the seed should only be shown once and then never again. This should be the default option.

@wigy-opensource-developer

Oh, this is great to implement as an opt-in feature, although an advanced user one. And then you could even store the derived master key instead of the seed phrase and really forget about it on the phone.

@Slesarew
Copy link
Contributor

Might go well with other options #871

This is a bit too many choices for the user though... but super-secret and moderately-secret seeds could co-exist nicely in fact. We just need to make probability of mistake small enough.

@kirushik
Copy link

I'm also a bit concerned about having too many potentially destructive opt-in features in Signer.
I am also not 100% sure there's a big security gain in not storing the seed phrase; I'd prefer to do another round of threat/security modelling and then use those models to help us decide here.

tag:tinfoil it indeed is, at least for now

@Slesarew
Copy link
Contributor

Maybe we should allow some more automated and foolproof profiling for Signer app. Something like settings that user can only set after reading the manual - for example, require scanning a payload that could only be generated from command line and signed and parsed by user first. Something messy to set up once but easy re-use for the same user.

Or we could bind the dangerous settings to verifier certificate. Thus the verifier would be an authority not only on upgrades but also on security protocols.

Just a bit of brainstorming after power outage. Well, it would be nice to build something really community-oriented around these security concepts.

@krodak
Copy link
Contributor

krodak commented Mar 23, 2023

Not requested by users and not related to any item on roadmap, we'll reopen if it will be requested by users and prepared by @tetekinandrey as feature to add, closing for now 🙏🏻

@krodak krodak closed this as completed Mar 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants