`infisical run` asks for `file` Vault password multiple times

[NiklasRosenstein]

Describe the bug

When using secrets from a project/folder that have references, the infisical commands that read the secrets prompt for the password of the file vault multiple times.

To Reproduce

1. Create a project
2. Create a secret A
3. Create a secret B with value ${A}
4. Run infisical vault set file
5. Run infisical init to connect to the project created in (1)
6. Run infisical secrets for that project and notice how you're prompted for the password twice

In my current setup I'm even prompted thrice.

Expected behavior

The infisical CLI prompts for the Vault password only once.

Platform you are having the issue on:

Linux

Additional context

Infisical CLI v0.12.2

[maidul98]

This is expected behavior because the CLI doesn't know what the passphrase is between command runs. To avoid entering the password each time, you can set the environment variable named INFISICAL_VAULT_FILE_PASSPHRASE

[NiklasRosenstein]

Hey @maidul98, good to know about this environment variable.

Your answer doesn't quite add up for me, though: There is only one invokation of the infisical CLI, and it prompts more than once. What seems to cause those multiple prompts is when you have a secret in your project that references another secret.

Surely there is an easy way to pass along the password of the first file vault unlock inside the infisical CLI (even if internally it calls itself again? which is what your response appears to imply).

[maidul98]

Oh i understand your issue. I think we can solve this by keeping a reference to the password in memory. Reopening to keep track of this issue. Thank you for the clarification

[sbshah97]

Any chance I can take this issue up to start off. I'd love to contribute to the repo and this seems like an ideal starting point ?

[akhilmhdh]

hey @sbshah97 are you still working on this issue

[sbshah97]

Hey I had gotten railroaded. Looking to pick this up again now if that's okay

[sbshah97]

I was looking to get some insight on how to get started. Any chance you could help?

[imiric]

Hey, could this issue be prioritized? :pray:

I'm running Infisical CLI v0.26.0 on Void Linux without systemd or a keyring service, so the file vault is my only option. This issue makes it difficult to use the app, since in my case I'm prompted for the passphrase dozens of times. The INFISICAL_VAULT_FILE_PASSPHRASE env var is not a secure solution because it exposes the passphrase to the system and other processes.

[maidul98]

Just wanted to let you know that Infisical CLI version v0.27.0 should allow you to preserve the password without using environment variable to set it. Once you update, you can run infisical vault set file --passphrase <your-passphrase>.

[imiric]

Thanks @maidul98. But am I interpreting the changes in #2184 correctly, and the passphrase is now stored unencrypted as base64 in the configuration file? :scream:

If the vault contains login credentials and secrets, then that effectively gives anyone with access to the configuration file, access to my Infisical account and all of its secrets. This is not much more secure than the environment variable workaround, and perhaps it's even worse, since the passphrase is stored indefinitely there now.

Unless I'm missing something, I would strongly suggest you rethink this functionality. A more secure approach would be to have sessions that expire with a configurable timeout, and for the vault to not store login credentials, but single-use session tokens. I'm not a security expert, but this is how CLI tools like Teleport work. I would encourage you to consult with a security expert on this matter.

[akhilmhdh]

@imiric it depends.

The file storage is a fallback if keyring access is not possible or not existing. The most suitable place is keyring.

Now regarding the next fallback is the file. The important thing here is that it's better than the environment variable because you can always control the access to that set of folder but if in environment variable there is nothing blocking like that in permission anyone can read it from anywhere.

We took inspiration from aws, vault and other cli agents out there.

[imiric]

The file storage is a fallback if keyring access is not possible or not existing. The most suitable place is keyring.

Right, but some systems don't have a global keyring, so the only choice is a file.

The important thing here is that it's better than the environment variable because you can always control the access to that set of folder but if in environment variable there is nothing blocking like that in permission anyone can read it from anywhere.

I suppose that's true. ~/.infisical/infisical-config.json has 600 permissions for me, but that's not very strict, since any other process under my account can read it. I could go out of my way to create an infisical user so that it's the only account that can read it, but that would be a hassle to implement in practice since the commands run by infisical run should have access to my personal files.

We took inspiration from aws

How? The AWS CLI requires secret/access keys to be stored in ~/.aws, but these have very configurable scopes of what they can access, and they can expire.

Additionally, there are tools like aws-vault that make managing these keys easier and more secure, and they also use system keyrings or an encrypted local file. The difference is that the encrypted local file uses JWT, which is a session token that expires. You might want to consider using their keyring library, and not dealing with this yourself.

I'm not familiar with how HashiCorp Vault handles authentication, but I would be very surprised if it's controlled by an unencrypted passphrase with no expiration.

[maidul98]

Hey @imiric, we use the exact same encrypted file implementation as https://github.com/99designs/keyring. In fact, the source code was taken with credit from there.

You do not by default have to use the encrypted file vault with passphrase, we give the choice back to the user on how they want to store the token. As for expiring token, yes, the token that is being stored will expire once the login session expires.