Storing variable number of username/password credentials in configuration node

Developing Nodes
1

I need to connect to a large number of authenticated sources of the same type (say, 100). I have a node that can communicate with one source, but using one authenticated node per source makes the flow completely unreadable and unmanageable with more than, say 10, sources. I really need to make one node that encapsulates all these sources and can contain a variable number of credentials. The node would receive a request as input payload, farm them out internally to all configured sources, and output individual, or maybe aggregated, response payloads.

I would therefore be great to have one configuration node with a variable number of username/password credentials, which would then get stored in node-red's credentials file. However, it looks like credentials can have only a static number of properties, e.g.,

credentials: {
         username: {type:"text"},
         password: {type:"password"}
     }

I suppose I could create 50 or so static credentials:

credentials: {
         username_0: {type:"text"},
         password_0: {type:"password"},
         username_1: {type:"text"},
         password_1: {type:"password"},
         ...
     }

and then dynamically use only the ones that I need for a particular list of sources. This feels like overkill and has an upper limit.

The package node-red-contrib-credentials approaches this problem with a configuration node that has a variable number of username/password pairs. It managing the password visibility itself, and it stringifies all usernames and passwords into:

credentials: {
         creds: {type:"text"}
     }

The problem with the approach is that the passwords inside creds are now visible to the editor, which is not acceptable in my application.

I suppose I could work with a simple configuration node per source with the typical static credentials:

credentials: {
         username: {type:"text"},
         password: {type:"password"}
     }

and then create a node that uses a variable number of these configuration nodes? But could I then create a (meta-)configuration node that depends on a variable number of these simple configuration nodes?

So I am clearly stuck on this. Thanks for any suggestions.