If a default value is specified for a Password Parameter in a job, Jenkins is only able to use the default value when the user executing the job is has Configure rights to the job. If the user has only build access, Jenkins will not fail to use the default value and instead send "****"'.

Steps to reproduce:

1. Create a job in 1.651.2 with a Password Parameter that has a default value.
2. Execute the job as a user who does not have Configure access to the job (maybe Read or Extended Read).
3. try to echo the parameter's value or save it to file
4. Jenkins will send **** instead of the actual value

This occurs without using Mask Password Plugin, meaning Jenkins is not masking the password but actually sending **** as the value.

I believe that Jenkins is not able to properly extract the default password from Secret because of SECURITY-266
"Users with extended read access could access encrypted secrets stored directly in the configuration of those items."

Note that people upgrading from 1.642 with already configured password parameter jobs will have issues upgrading to 1.651