There are currently 2 ways to mask passwords.
A) Mark a build variable as sensitive. This works for any Maven or Ant build as they will mask the sensitive variables when used. The Core Jenkins team needs to extend this to all command line tools. Yet the will have no other choice than to re-use the mechanism as implemented by the "Mask password plugin" as these build steps have no mean of sensitive variables (expect something like echo off).
B) Use a custom log formatter to mask any occurrence of a given variables content. This will work is currently implemented by the "Mask passwords plugin" and "Credentials binding plugin" (yet only for the pipeline step).
Variant B will fail under some circumstances to match all secretes in the output log. Its internal implementation will create as soon as it knows all secrete variables values a large regex pattern such as "secret|mysecret|anothersecret".
As you may guess this will fail to match all secrets in the log correctly as "secret" will always match also "mysecret" and "anothersecret" before even checked against those ones.
The pull request will fix this by ordering the sensitive variables values by there length and constructing a regex pattern, that will try to match the most complex secrets first, e.g. "anothersecret|mysecret|secret".
In addition to that, anything that closely matches the sensitive variable content will be masked. Such as path that may contain by mistake the secret value, e.g. /some/path/to/secret/files/on/disk is masked as /some/path/to/****/files/on/disk. Anyone with a decent amount or read access to the workspace may figure out what has been masked. To circumvent this issue, you should use passwords that have a solid random [a-zA-Z0-9!\.«@.] (at least on number, lower and upper character and special characters).