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.
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.
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?
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:
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:
set a flag to hide or not all the fields in all credentials marked as password.
create a flag that is per field per password, like āWrite only storeā, that those flags are never returned, but the others are.
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.
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ā¦