Encryption/Decryption of passwords not working as expected between restarts

Issue #887 resolved
created an issue


Following issue #886, I'm using the security API provided by SCM-Manager in order to encrypt some passwords during automated configuration (the password I'm encrypting is for the proxy configuration, so the SCM-Manager client is of no use, as it does not provide the proxy configuration as an API).

After SCM-Manager is started on some port locally, here's what I do:

# $1 : server port
function login_as_admin() {
    curl \
         --data username=scmadmin \
         --data password=scmadmin \
         --cookie-jar /tmp/scm-cookies \
         "http://localhost:${1}/api/rest/authentication/login" \
         1>/dev/null 2>/dev/null

# $1 : server port
# $2 : secret
function encrypt_password() {
    curl \
         --cookie-jar /tmp/scm-cookies \
         --cookie /tmp/scm-cookies \
         --data ${2} \
         "http://localhost:${1}/api/rest/security/cipher/encrypt" \

login_as_admin 6666
if [[ ! -z "${http_proxy_password}" ]]; then
    http_proxy_password_hash=$(encrypt_password 6666 ${http_proxy_password})

After that, I put the password hash in the config.xml file:

sed -e "s/{PROXY_PASSWORD}/${http_proxy_password_hash}/g" \
       -i ${SCM_HOME}/config/config.xml

After I restart the server, I test the proxy configuration by trying to download the list of available plugins, which fails. If I then manually configure the password in the general configuration screen, and save, it then loads the list of available plugins sucessfully.

Please note that those scripts "work" (I have the cookie with the JSESSIONID store in my cookie jar file, and I get a hash as the output of the call to the encrypt REST API).

Thus, apart from me making some mistake / assumptions on how the API works, it seems the API behaves differently than the GUI. And as the password is salted, I have no simple way to reproduce / test the hash produced by the encrypt REST API...

Comments (14)

  1. bardelotnzl reporter

    I have the same issue with the config REST API. I post a JSON file containing the proxy password in clear text, but when I read back the configuration the password does not decode to the original value.

  2. bardelotnzl reporter

    I do not see a unit test that validates encode and decode methods so that decode(encode(input)) = input. It might be a good idea to add one, as I begin to suspect there might be an issue in those.

  3. bardelotnzl reporter


    When encoding the SecretKey used in the inital vector of the cipher in ENCRYPT_MODE is based on the value of key, which is always the key stored in .cipherkey.

    But, when decoding the SecretKey used in the initial vector of the cipher in DECRYPT_MODE is based on the value of plainKey. And that value is the same as key EXCEPT when the program's trying to load the .cipherkey after startup (and in this case key is null and plainKey is the BASE_KEY hard-coded in the class.

    That's also why the variable plainKey is never actually used in decoding, while still passed as the first parameter of the method (Eclipse or IntelliJ should warn you about this...).

  4. bardelotnzl reporter

    From where I work I cannot submit a patch, but the fix is very simple:

    SecretKey secretKey = buildSecretKey(plainKey);

    instead of using key in the method decode of DefaultCipherHandler.java

  5. bardelotnzl reporter

    Thank you Sebastian, my tests work fine now :)

    Might I ask for 1.51 including this patch? I don't know your release schedules/policy for the stable branch (1.x if I'm not mistaken).

  6. Log in to comment