[Requesting Feedback] New Encryption Passphrase Workflow

We would like to get some feedback on the new encryption passphrase workflow. It is deployed on the QA satellite. Please give it a try and share your thoughts with us.

What has changed:
The encryption passphrase for the file browser is set on the project level. Changing buckets doesn’t require entering it over and over again.

Known issues
Changing the passphrase is possible. We are missing some kind of tool tip that explains to the customer how to find the menu for changing the passphrase. It is hidden under the project drop-down menu.

Logout or switching projects will clear the passphrase. In the original design, this feature was designed to be opt-in. The engineering team pointed out that the most secure way to store the passphrase would be inside the browser object like we are currently doing anyway. That removes the opt-in idea because as long as the file browser is open the passphrase is stored in the browser object regardless of customer choice. Opt-out only means it gets cleared earlier.
However, there is one downside. Since we don’t persist the passphrase in the session or local storage, it will also be cleared by pressing F5.


Sounds good in principle, but a lot of it would depend on how the UX is implemented and what information is provided alongside it. I’d love to check it out if it gets rolled out to a validation satellite.

It will help prevent users from thinking the pass phrase is tied to a bucket for some reason. The old UX kind of suggested that (in some cases even explicit said that).

The new UX is available on the QA satellite. Just imagine that the UI gives you a hint about where the menu for changing the passphrase is located (see the known issue section).


US2, right? I don’t seem to be getting the activation email… I’ll give it a few more minutes.



Right, my bad.

So it looks like most of the UX remains the same, still suggesting the passphrase is somehow tied to the bucket. The onboarding flow has you create a first bucket and set a passphrase for that bucket. That context still doesn’t make sense to me since the passphrase is tied to objects (or your session), not to buckets.

I also noticed that in the manage passphrase screen you have options to create a new passphrase or switch passphrase, which is essentially the same thing except the first allows you to generate or enter one, while the second only allows you to enter it. Since you’re not creating anything, just switching the passphrase for your current session, I would suggest merging these options under the switch passphrase terminology.


When you first sign up, the box says that each bucket should have its own passphrase but then when you create a new one it doesn’t ask you for a new passphrase. So I’d think the wording needs to change on the new user 1-2-3 step boxes to reflect the new concepts.

You could also put on that 1-2-3 step process that if you want to change the passphrase, you can via the project menu dropdown, but if I had to guess independently it’d be in the “access” section under bucket default passphrase or something like that.



That’s indeed very confusing. Let me link to the discussion we had about this in the past, maybe contains some ideas that are useful:

1 Like

Not sure if this is relevant? But will post anyways.

I’m using s3f3, and it’s working! The S3 credentials are the same passphrase as the one created for the bucket, so I’m not sure what went wrong.

It is relevant. There is something wrong with that message. A fix is already been worked on: https://review.dev.storj.io/c/storj/storj/+/9768


Good to know! I’m just curious, are you saying it is wrong as in the fact that it shouldn’t show up? Or are the numbers wrong?

If you want to be on the safe side you can do an uplink ls --recursive with and without --encrypted. If they both show the same number the message should not show up. If the number is different it would mean you have files in that bucket that can’t be decrypted with the current encryption key.

The UI should make that comparison but unfortunately, there is a bug. After fixing that bug I would expect the number to change. If it drops to 0 the message will disappear. Even if we call it a bug it doesn’t mean that fixing it will remove the message entirely. You might have a few files with a different decryption key without knowing it. That is why we implemented that message in the first place.


Thanks for the reply. Do you have any updates on when that fix will be deployed?

I would expect that fix to get deployed next Monday but lately, we postpone the release more often so let’s say sometime next week to be on the safe side.


Cool. Btw, after checking with uplink then counting the lines with AWK with and without --encryption, it is the same number.