Workaround is to use the Mask Passwords plugin.

Jesse, i'm looking for just this particular workaround until this issue is resolved. My jobs are not using credentials as parameters, but the credentialsBinding DSL/ "Build environment -> Bindings" setup. My combination of Jenkins Credentials Binding Plugin and Mask Passwords plugin (LTS/ latest/ latest) shows credential passwords. Could you please elaborate on what you did to mask those?

Any insights greatly appreciated.

Having same issue. Android gradle commandline doesnt work with mask password or envinject plugin to pass password as build parameter. Any idea would really helpful.

I also couldn't figure out any way to make the "Mask Passwords Plugin" work with the "Credentials Binding Plugin", so if anyone has advice on the supposed workaround I would really like to hear it! (I, too, am passing a secret on the gradle command line - in my case using "-D", since this needs to work smoothly both on Jenkins and in a local IDE, and referencing env vars directly in the gradle script is troublesome locally.)

Of course, even better will be when a workaround isn't needed anymore - looking forward to the "Credentials Binding Plugin" being able to do some kind of password masking in the output.

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).

This sounds like good hints to implement a fix.

But does anyone have a workaround (for shell/batch build steps) - with use of Credentials plugin?

Without Credentials plugin, possible Workarounds are env inject plugin or mask password plugin, which mask correctly.
But they use directly entered single passwords in the job config (mask password addtionally global passwords).
Also both are not useable for templates, as templates only have Credentials parameter type.

After this discussion
https://groups.google.com/forum/#!topic/jenkinsci-users/GgX3RSckVlI
I found out that this issue occurs in freestyle job only and not in pipeline.

Test cases:
1. Freestyle job -> both username and password visible in the log
Restrict to label "OS:Linux"
(X) Use secret text(s) or file(s) -> Username and password (separated) -> Env vars USERNAME and PASSWORD
Add build step shell
env
echo $USERNAME $PASSWORD

2. Pipeline -> both username and password masked as **** in the log, but successfully injected (verified in test.txt)
node ('OS:Linux') {
withCredentials([[$class: 'UsernamePasswordMultiBinding', credentialsId: 'bccee5af-b682-407b-9171-43e38723460a', passwordVariable: 'PASSWORD', usernameVariable: 'USERNAME']])

}

Apologies as this may be a mild hijack of this issue, but I want to find out whether this edge masking case warrants a JIRA and whether one already exists (don't think so, I just scanned all with component = credentials-binding-plugin).

Minimal reproduction script is:

node() {
  withCredentials( [] ) {
      echo 'Test of the credentials binding decorator'
  }
}

So, passing an empty list of credentials--my concrete use case constructs the list based on upstream factors; some of the times there are no credentials to resolve so the list is empty. The relevant part of the log then winds up like this:

[Pipeline] Bind credentials to variables : Start
[Pipeline] withCredentials {
[Pipeline] echo
****T****e****s****t**** ****o****f**** ****t****h****e**** ****c****r****e****d****e****n****t****i****a****l****s**** ****b****i****n****d****i****n****g**** ****d****e****c****o****r****a****t****o****r****
****
****[Pipeline] } //withCredentials
[Pipeline] Bind credentials to variables : End

I believe it's because BindingStep.Filter::Filter builds a zero-length pattern in this scenario, which matches like crazy.

Is this a bug?

jglick, thanks. It's JENKINS-34823. Entered as a Priority: minor.

Just curious if there was any recent movement or potential fix for this on credential-binding for FreeStyle jobs

As this article states this is "current best-practices" maybe then some effort should be made to kill the bugs of the credential bind plugin that makes the best practice insecure. This ticket has been open for 2 years. Due to this bug the plugin is disabled in our company, leading to yet more hack workarounds that sap our time. Please fix!

One more attempt at a PR up for review - https://github.com/jenkinsci/credentials-binding-plugin/pull/28

Code changed in jenkins
User: Andrew Bayer
Path:
src/main/java/org/jenkinsci/plugins/credentialsbinding/MultiBinding.java
src/main/java/org/jenkinsci/plugins/credentialsbinding/impl/BindingStep.java
src/main/java/org/jenkinsci/plugins/credentialsbinding/impl/SecretBuildWrapper.java
http://jenkins-ci.org/commit/credentials-binding-plugin/a47f4b8529fd216c3c797566aa969191834abd7a
Log:
JENKINS-24805 First work on masking secrets in freestyle logs.

This still needs tests - I just want to make sure the approach is right.

Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/org/jenkinsci/plugins/credentialsbinding/MultiBinding.java
src/main/java/org/jenkinsci/plugins/credentialsbinding/impl/BindingStep.java
src/main/java/org/jenkinsci/plugins/credentialsbinding/impl/SecretBuildWrapper.java
src/test/java/org/jenkinsci/plugins/credentialsbinding/impl/SecretBuildWrapperTest.java
http://jenkins-ci.org/commit/credentials-binding-plugin/d2bcf977eb334ee93774c94d8db1007afc5cad41
Log:
Merge pull request #28 from abayer/jenkins-24805

JENKINS-24805 Start masking secrets in freestyle logs.

Compare: https://github.com/jenkinsci/credentials-binding-plugin/compare/686a29f57bf7...d2bcf977eb33

Thanks a lot for implementing this! Which version of plug-in would have these changes?

It'll be in the next release, 1.10.

…which is released.