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

Remember export passphrase for session length #667

Open
eloquence opened this issue Dec 16, 2019 · 6 comments
Open

Remember export passphrase for session length #667

eloquence opened this issue Dec 16, 2019 · 6 comments

Comments

@eloquence
Copy link
Member

Currently the user has to re-enter the passphrase for each export, which can get quickly tedious if they are exporting a lot of files.

We should, optionally, remember the passphrase (in memory) for the duration of a session. It would be reset if it fails to successfully unlock an export drive the user attempts to export to.

@eloquence eloquence added enhancement New feature or request ux security labels Dec 16, 2019
@eloquence
Copy link
Member Author

eloquence commented Dec 16, 2019

Should there be a "remember for the duration of this session" (language to this effect) checkbox here and, if so, should it be checked by default?

IMO yes (there should be a checkbox) and no (it should not be on by default). We want the user to understand why they no longer have to enter the passphrase, and we don't want them to worry that they're accidentally using an unencrypted drive. By making this an explicit choice we give them agency as to how credentials are managed.

@eloquence
Copy link
Member Author

(Not milestoning yet until we have agreement on whether to do this & minimal scope for a first iteration.)

@sssoleileraaa
Copy link
Contributor

Instead of storing user passwords client side, I think we should provide a checkbox for keeping the device unlocked, see freedomofpress/securedrop-export#39 (comment) where it was decided to err on the side of caution to relock every time. We could add a json boolean to our sd-archive file that we pass to the export vm to tell it to skip the re-locking phase.

@eloquence
Copy link
Member Author

eloquence commented Dec 16, 2019

I like that suggestion, it would have the additional benefit of allowing the user to interact with the drive more naturally in the VM if they want to do so. And it seems sensible to avoid writing creds into memory in the sd-svs VM if we don't need to.

Also, it somewhat eases concern about a potentially long-running workstation retaining a cred in memory well past the use of a drive.

The only downside I see is that the user would have to retype the passphrase if they do a sneakernet run back and forth (unplugging and re-plugging the drive), but that seems an acceptable tradeoff.

@eloquence
Copy link
Member Author

Closing in favor of #1734

@rocodes
Copy link
Contributor

rocodes commented Jan 26, 2022

So after talking to @creviera yesterday, I think we should re-open this issue, because it's different from #1734. That issue is about a specific bug (user unlocks encrypted drive outside of SDW export workflow, still has to enter passphrase); this issue is about a general user flow ("should we offer to persist the user's passphrase for a certain amount of time in a similar manner to Nautilus?") and this one would require UI changes.

(Attaching a screenshot of the current 'persist passphrase' options on sd-devices just for a visual comparison of the same workflow outside of SDW, although we wouldn't offer a 'remember password forever' equivalent since that would require writing it to disk.)
sd_devices_unlock_options

@rocodes rocodes reopened this Jan 26, 2022
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

3 participants