-
Notifications
You must be signed in to change notification settings - Fork 42
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
Comments
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. |
(Not milestoning yet until we have agreement on whether to do this & minimal scope for a first iteration.) |
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. |
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 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. |
Closing in favor of #1734 |
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.) |
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.
The text was updated successfully, but these errors were encountered: