Question about Managed Passphrase Security Model

Developer Discussions
1

Hi Storj team,

I’m trying to better understand the security model behind satellite-managed encryption.

From my understanding, when a project uses a managed passphrase, the satellite stores the passphrase encrypted and can later decrypt it when needed. However, it appears that an authenticated project member can retrieve the decrypted passphrase through the project configuration endpoint:



GET /api/v0/projects/{project-id}/config

If the response contains the plaintext passphrase, then the passphrase is ultimately exposed to the browser for authorized users.

My question is:

  • Doesn’t returning the decrypted passphrase to the client introduce additional security concerns?

  • For example, if a browser session is compromised, an XSS vulnerability exists, or someone gains access to the user’s authenticated session, could the managed passphrase be exposed?

  • How does Storj evaluate and mitigate these risks in the managed encryption model?

  • Is the expectation that users of managed encryption trust both the satellite and the authenticated browser session, whereas users requiring stronger privacy guarantees should use user-managed encryption instead?

I’m not questioning the design choice itself—I’m trying to understand the intended threat model and the security considerations behind exposing the managed passphrase through the project configuration API.

Thanks!

2

Hello @der,
Welcome to the forum!

I would say that users, concerned about their security, should always use only manual managed encryption and generate access grants only locally, using uplink CLI and the API key + satellite URI, where they will be asked for an encryption phrase locally, and the generated access grant will also be available only locally and invisible in the Storj Console.

I forwarded your question to developers.

3

I think this is a good description. The managed encryption is for improved usability not for improved privacy.

Other note: the user managed encryption (if used form web ui) is also on the browser side. From this point of view we have the same attack vectors on browser side, no big difference between managed / non-managed.

Yeah, if a browser session is compromised that can include the browser side encryption key, even for normal (not managed) encryption keys. And it would likely enable to access anything.

For the highest privacy (as @Alexey wrote), you shouldn’t use UI, just API key + uplink.