In NSE creds library the first argument of Credentials.new(...) is at moment a string used mostly for debugging purpose, and it is called scriptname, this way it is not very useful while with little or no change it could be used as a name for the credential storage, making easier for different scripts sharing the same credentials/protocols to coordinate.
At moment if from a script or a library you need to access credential generated by other scripts like a *-brute script you have to pass creds.ALL_DATA as first argument and iterate over the whole storage, then you have to discern what is the credential you need between all credentials that share host and ports with the one you are interested in, this may result in a complicated problem.
To understand better the situation let's imagine the user run something like
nmap -p 80 --script=joomla-brute --script=wordpress-brute --script=wordpress-escalation --script=joomla-logbang mypoorserver.poo
assiming that joomla-logbang needs credential bruted by joomla-brute and that wordpress-escalation needs credential bruted by wordpress-brute
No problem for *-brute scripts that use SCRIPT_NAME to store the credentials they found but what will happen to both joomla-logbang and wordpress-escalation ?
They will iterate over the the whole storage passing creds.ALL_DATA and they will be not able to discern what is the credentials for wordpress and what is the joomla one.
If instead of SCRIPT_NAME we would use a service oriented defined constant like "http.wordpress" and "http.joomla" or "snmp.communities" as you can see on this branch
Scripts would not suffer and get the credentials they needs in a whim.
I have renamed the branch to hotfix/159 so you can find it at
The direction makes sense to me but in large enterprise environments it is not uncommon to see multiple instances of the same server app running on different ports on the same server. This means that the point Gio is raising still does not completely go away with the proposed change of tagging just by application.
That said, my personal approach to the more offensive NSE scripts (such as brute-forcing credentials) is that I almost exclusively target only one application instance at a time anyway so I do not have much problem with how things work right now.
After a discussion with dmiller I have done some experiment to use that argument as a table so a credential can have multiple "tags"
It is already functional but not so optimized, to improve performances a bytag index is created but at moment is not really used at credential retrieving
nselb/creds: Fix #159, Add support for credential multitag