I am exploring the possibility of exporting the decrypted credentials through the command-line interface (CLI) with an authentication mechanism in place. As a professional in Cybersecurity, I believe this feature is essential, or I would like to know if it is already available. While I appreciate the ability to export plain-text credentials from the command line, I believe these should be safeguarded by an authentication method.
I am referring to this feature: [CLI commands | n8n Docs]
Thank you!
Information on your n8n setup
**n8n version: 1.86.1
**Database (default: SQLite): SQLite
**n8n EXECUTIONS_PROCESS setting (default: own, main): own
**Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
Hi, I guess the request is that whenever you perform the command to get the credentials unencrypted, there would be an authentication / password whatever.
In general, if the machine would be locked down and access would only be possible through SSH or a jumphost it would not be that bad.
But anyone able to create a workflow, can execute a command node to export clear credentials commands without any obstruction.
I apologize if my question wasnât clear enough.
I am looking for a way to restrict the ability to export decrypted credentials from the command line using the n8n tool without requiring a password. Currently, anyone with access to the machine running the n8n application can execute the command n8n export:credentials --all --decrypted and gain access to all stored credentials in an unencrypted format.
While I find this functionality very useful for migrations, I would like to have some form of authentication for it. For example, requiring a âmasterâ password before proceeding with the export would enhance security.
I agree, and the machine is beyond a jumpbox, but as we know, in security we refer to âwhenâ, not âifâ a machine would be compromised, so this is just an extra precaution in that direction.
Iâm curious: if the CLI were to require a âmaster passwordâ for exporting credentials, where would this password be stored or validated?
If itâs stored on the same machineâwhether in a database, environment variable, or config file, it introduces a similar risk, Anyone with access to the server would likely be able to retrieve or bypass that protection, especially since they already have file system and process-level access.
As long as the password is hashed and not in clear-text itâs good to go. The only things that needs to match is the hash of the provided password compared to the hash of stored password. The password can be stored in the DB. If needed it can be encrypted as well. Nothing is impossible but this is how any user password is stored on sites. Hashes
Okay, but you already have access to the server, you still can just replace the stored hash with one generatedâso you can still authenticate and export credentials, so this is just an extra complexity layer, not real security!
Hi, depends if you create a table that has read-only and the N8n dB user has no access. Etc. and the global admin is not injected in the env. Anyway. Anything is possible. If you have enough time
That is correct. The password hash would be stored in the same database as the other passwords, but hashed with an encryption key (N8N_ENCRYPTION_KEY).
Now, you could argue that if someone gains access to the host running the n8n application, they would also be able to obtain access to the N8N_ENCRYPTION_KEY variable, which may lead to the possibility of decrypting the entire credentials database at some point. Still, this is a bit more advanced step, and I still think requiring a password for the ân8n export credentialsâ is a good step in the right direction.
You raise an excellent point that significantly changes the way I view this issueâit clearly constitutes a security vulnerability.
In any shared environment where users have permission to create workflows, they could easily add an âExecute Commandâ node and run something like ân8n export:credentials --all --decryptedâ. This command would grant them access to all stored credentials in plain text, completely bypassing any user interface restrictions.
This means that even without access to the host machine, a user could still extract all sensitive credentials, which poses a major security risk.
Given the severity, this might be more than just a feature requestâit likely qualifies as a security vulnerability.
I donât think the self-hosted community edition of n8n is really intended for âshared environmentsâ
So If we are referring to an Enterprise setup, it indeed includes stricter security
External secret store integration
Fetch secrets from an external source without ever saving them in n8n. We support AWS Secrets Manager, Infisical and HashiCorp Vault.
By âshared environmentâ, I did not refer to the userâs ability to share their workflows with others, but rather an environment with multiple users. Perhaps âmulti-user environmentâ is the more accurate term (which could be common even for the Community Edition).
So hereâs how you can test it:
Create a user account and add any credentials using this user.
Create another user account, but do not create any credentials for this user.
From the second user, create a workflow that includes an âExecute Commandâ node and executes this command: 'n8n export:credentials --all --decryptedâ.
The second user will have access to all credentials stored in the n8n instance, regardless of their ownership.
I consider this a significant security vulnerability that requires immediate attention.
I just replicated thisâyouâre absolutely right!
After creating another user (Member), everything appeared freshâŚ
But when executing n8n export:credentials --all --decrypted in the Execute Command node, surpriseâI got all the credentials!
Iâm not sure if this is intended behavior or if itâs because all users share the same database. I donât know, to be honest. But thanks for pointing this outâitâs definitely something to be cautious about.
@djangelic Could you please assist me in emphasizing this matter? I believe it should not go through the usual âfeature requestâ thread, as it represents a serious security issue.
Thanks for alerting me @CristianG , I spoke with our engineering team about this and they reassured me with a few things:
Firstly, the output mentions that this is something that is going to be changed in the future, so itâs definitely on their radar and not being ignored. However it is something that is completely fixable by the n8n server operator. As part of the output you get the following message: Permissions 0644 for n8n settings file /home/node/.n8n/config are too wide. This is ignored for now, but in the future n8n will attempt to change the permissions automatically. To automatically enforce correct permissions now set N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true (recommended), or turn this check off set N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false.
Secondly, in a shared environment, the execute command node is not recommended to be enabled for exactly this reason. This can be disabled following this documentation.
Part of the reason that the execute command node is not allowed in the Cloud instance is because of this, its a big risk to run commands on the server, not just this one. It can be used to tamper with the installation itself.
Let me know if this helps, or if you have a different concern about this. Thanks!
