Hide credential password

I would like to give other users access to n8n so they can create and update workflows. However I have a problem giving them access if they can just read out passwords from all connected systems.

As long as there is no user management / password store implemented as proposed in the request it would be good if we could have a flag to hide (***) passwords in the credential manager. This way users can use the system but are not able to read the credentials for other systems.

Hey @jwillmer,

Unfortunately, hiding a password behind *** is very easy to bypass. I think a better way of dealing with the whole password issue is to set up a form of two-factor authentication (2FA) so that users can still use the credentials but managers with the 2FA token/kep/app can manage the passwords.

It is not easy to bypass if the server returns ***** instead of the password.

Agreed.

Unfortunately, the *** masking is usually done by the web browser and trivial to bypass. But, I think that n8n can learn from these things.

Iā€™m pretty sure @jwillmer is not referring to using the password input type as protection, but rather not actually returning the credentials from the server at all, just using **** as a literal placeholder value. In lieu of user management and roles, those credentials marked as sensitive could be write-only from the UI?

Welcome to the community @pemontto!

Yes makes sense. Giving more fine-grained control over the credentials (like who can create, delete, update, use, see, ā€¦), workflows, ā€¦ is planned with User Management/User and Privilege Management. We will start to work on that very soon and hope we will have it ready in the next few months:

2 Likes

I think that itā€™s easy to implement it somehow. When returning the credentials from the server, replace sensitive fields with null or another dummy marker.

The problem I think is that sometimes you want to be able to retrieve this information, so controlling when to hide or not is seems to me to be the implementation issue. I did myself to get some secret in the N8N.

With user management, that could be done logically with per user permission. But for now, I see 2 options:

  1. set a flag to hide or not all the fields in all credentials marked as password.
  2. create a flag that is per field per password, like ā€œWrite only storeā€, that those flags are never returned, but the others are.
2 Likes

Bumping this one upā€¦ Iā€™m surprised this didnā€™t get upvoted more, as this is certainly a major barrier (together with user management) for larger organizations to use n8n, since these will always try to ensure as few people as possible need to know any secret (typically devops), while empowering as many people as possible to write code using these secrets (typically devs).

I donā€™t necessarily think this needs to be tied to user management, a simple write-only logic can work just fine without any handling of permissions / sharing, they can simply be made write-only, i.e. can be set (by anyone) but not read (by anyone) - Thatā€™s how e.g. Github, Azure Devops or Jenkins manage secrets: nobody (even devops) can read the sensitive fields once set - but can still be updated of course.

1 Like

Yes, also bumping it up. I totally agree that this should be implemented ASAP. This is also to me and my company quite a big concern.

I canā€™t belive n8n got so far and this issue still exist, i mean, how can one put a password in n8n and feel safe? or even worse, many passwords for many integrations and all in plain text (covered by ***)?
especially when you want to share it with multiple coworkers
n8n should not return the passwords to the client. should only return passwords to the executing workflowā€¦

2 Likes

They donā€™t seem interested in the matter.
I think it is necessary to pay more attention to security-related parts in order to be used in enterprise.

1 Like

Thanks for bringing this up ā€” weā€™re aware of this feature and have it on the roadmap to fix.

2 Likes

Got released with [email protected]

3 Likes

oh!!! awesome
itā€™s very good news thank you

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.