Seeking clarification on the login process

[garylai]

Hi,

I am evaluating infisical at work and come across a piece of code in the login flow which looks concerning so I'd like to seek clarifications.

In the 2 Step of the login process, it looks like the frontend is sending user's password in plain text to the server. And then the server uses it to decrypt user's private key and store a server side symmetrically encrypted version of it back to the DB: https://github.com/Infisical/infisical/blob/main/backend/src/services/auth/auth-login-service.ts#L275. (It seems it also happens when users complete their signup: https://github.com/Infisical/infisical/blob/main/backend/src/services/auth/auth-signup-service.ts#L400)

If it is the case, doesn't it mean that the server alone has enough information to decrypt secrets? Is it also potentially dangerous that user's password is sent to the server in plain text, given that it's used to decrypt user's private key? Please let me know if I misunderstood.

[dangtony98]

Hi @garylai,

Thanks for raising this inquiry — This is intentional and part of the platform's migration from an end-to-end encrypted (E2EE) architecture to a more traditional encryption-at-rest and in-transit scheme; this means that the server is expected to be able to decrypt secrets in order for features like secret rotation, dynamic secrets, and native integrations to work.

In the beginning, Infisical was more-so an encrypted key-value store with little to no automation/workflow requirements for which the E2EE architecture (involving the private key as you mentioned) made sense. As the platform grew, we got a lot of feedback and it became clear that to support certain features and workflows like the ones mentioned above, we needed to make a tradeoff, adjust the threat model, and migrate the architecture to a newer scheme which led to hybrid support and eventually fuller transition to encryption-at-rest and in-transit scheme (as part of this, we introduced a lot of new security measures such as an internal KMS module and support for connecting an external KMS to further encrypt/wrap secrets).

Let me know if that clarifies things for you — Happy to also chat about this further in the Slack here.