{{ message }}
Repository navigation
[BUG] Insecure permissions for configuration file holding hashed password & plaintext WiFi password #770
Description
Describe the bug
The configuration file which holds the hashed & plaintext WiFi has insecure permissions by default.
To Reproduce
on Linux:
$ ls -l "$HOME/.config/Raspberry Pi/Imager.conf"
-rw-rw-r--. 1 ricardo ricardo 775 Nov 19 12:13 Imager.conf
$ grep Password "$HOME/.config/Raspberry Pi/Imager.conf"
sshUserPassword=$5$xxx
wifiPassword=xxx
Expected behaviour
0600 permissions.
Activity
tdewey-rpi commentedon Jan 2, 2024
Thanks for the report, @ricardobranco777.
I can confirm I see the same, and will address this in a patch later this week.
imagewriter: Force permissions on settings to 600
audas commentedon Mar 2, 2024
Was under the impression that if we just re-used the passwords that were set in the imager that they would be correct - but they are not working for SSH.
So if I re-use a password for another Pi it is wrong as it has been hashed.
However the WiFi password remains correct???
tdewey-rpi commentedon Mar 4, 2024
@audas This sounds like a different problem, but also one that I would expect to be true, as I don't know if SSH uses the same hashing scheme as WPA-PSK. Please raise unique issues for unique problems.
Xalcon commentedon Mar 1, 2026
@tdewey-rpi I audited my
.configdirectory and noticed this behavior on version 2.0.6. It appears the issue discussed in this ticket is still present.Password storage: Currently, SSH and Wi-Fi credentials are written to the config file. Even though the SSH password uses a hashed form, storing secrets in a config file by default can pose a risk. It may be safer to make this opt-in or provide a more secure mechanism for secret storage.
Root execution and file location: The switch to requiring root for block device access introduces some complications on Linux desktop environments, especially with Wayland. When running via
pkexecwith environment passthrough, the config file ends up in the user’s home.configdirectory but is owned by root. This happens because the GUI session information is used to resolve the config path, even though the process is running as root. The result is a root-owned file with 644 permissions in a location intended for user-owned files. I might be doing something wrong when executing rpi-imager via pkexec, but a lot of other users may do so as well.Recommended improvements:
600) and be owned by root.These adjustments would align the application more closely with Linux security and XDG conventions while reducing risk for user credentials.
Just for completeness sake, this is how I have to execute rpi-imager at the moment for it work at all:
It is obviously possible to run with just
sudo -E rpi-imager, but that exposes all user env variables - no sanitation is done.tdewey-rpi commentedon Oct 21, 2026
2.0.12 shipped with the fix for this.