Losing passwords due to german umlauts and maybe other symbols

[Phorms]

Hi,

we found a strange bug by losing passwords since version 3.2.0 or 3.2.1. We installed both versions this week and are not sure which version introduced the issue.

Steps to reproduce:

1. Use an old account and decrypt the password.
2. Add a problem symbol of your choosing to the password, we tested ä ü ö and ß .
3. Save.

The password can no longer be decrypted (without an visible error). The password field stays empty.
The same problem occurs at account creation.

Details:

• No SQL or PHP errors are logged.
• The database field encrypted_password has still content and it changes once the problem symbol is saved.
• It could be possible that the password does not need to be changed when is has already a problem symbol included and only a other field was changed / saved with a decrypted password. (hard to test since this needs an already affected account)
• We are pretty sure more symbols are affected since most password generators don't use german umlauts.

[Phorms]

Tested with Firefox and Chrome.
GLPI version 11.0.6
Accounts plugin version 3.2.1

[blainvillem]

Hello,

We're having the same issue and have lost a lot of passwords.

Is there a way to recover them? I tried downgrading to version 3.1.17; the passwords are displayed, but they're nothing like the original ones.

I tried deploying the master version of the plugin; now the TOTP field and the fingerprint field are displayed, but the password still doesn’t show up—the decryption leaves the password field empty.

Do you also know of a resource that explains what the fingerprint is used for?

Thank you in advance for your prompt assistance with this matter.

[blainvillem]

Hi,

I did some additional investigation on this issue.

Environment:

• GLPI 11
• Accounts 3.2.1
• Also tested with the current master branch including commits 5990de7 and a079775

What I observed:

• Legacy passwords (without the $v2$ prefix) decrypt correctly.
• Passwords saved using the new $v2$ format cannot be decrypted correctly.
• Initially, the browser throws a Malformed UTF-8 data error.
• After applying the fixes from master, the error disappears but the decrypted value is still unreadable binary garbage.

Example of a working legacy password:

ncSZYn5+fn7QfvtD2nZe5seCf+YNWre55MpQZ910

Example of a broken v2 password:

$v2$sLTGnw5YTiRkVnjqU8lrGQ==$a5Piefxqlymg

I also tested the PHP implementation directly from AccountCrypto.php using the same fingerprint key:

$ciphertext = '$v2$sLTGnw5YTiRkVnjqU8lrGQ==$a5Piefxqlymg';
$fingerprint = '...';

$parts = explode('$', ltrim($ciphertext, '$'));

$iv  = base64_decode($parts[1]);
$ct  = base64_decode($parts[2]);
$key = hash('sha256', $fingerprint, true);

echo openssl_decrypt(
    $ct,
    'AES-256-CTR',
    $key,
    OPENSSL_RAW_DATA,
    $iv
);

The result is still unreadable binary data instead of the original password.

This suggests that the issue is not limited to the Javascript decryption code. What I can confirm is that passwords stored in the $v2$ format cannot be correctly read back, even when using the PHP decryption logic provided by AccountCrypto.php.

At the moment I have approximately 172 accounts stored in the $v2$ format that are affected, while all legacy accounts continue to work correctly.

As a temporary workaround, I reverted encrypt_password() to use the legacy AESEncryptCtr() method, which prevents newly modified accounts from becoming unreadable.

Please let me know if there is any additional debugging information I can provide.

[Phorms]

Hi @blainvillem ,

we "rescued" our passwords by restoring the old hashed password values directly into the database from a backup.