SUMMARY KDE Wallet prompt pops up after login using a new password and does not accept the new password, instead accepting only the old one. This could be exploited. STEPS TO REPRODUCE 1. Update user password using `passwd` 2. Reboot 3. Log in via SDDM 4. insert new password on the prompt, prompt fails 5. insert old password, prompt succeeds SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 Kernel Version: 6.10.2-arch1-1 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i3-6006U CPU @ 2.00GHz Memory: 7.6 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 520 ADDITIONAL INFORMATION
Yup, this is why you should change your password using the GUI, which prompts yo to change the KWallet password as well. If you use `passwd`, this is up to you to know and remember to do.
(In reply to Nate Graham from comment #1) > Yup, this is why you should change your password using the GUI, which > prompts yo to change the KWallet password as well. If you use `passwd`, this > is up to you to know and remember to do. Oh, that's fair I guess, sorry for bothering y'all; I'm just a diehard CLI fan, so perhaps this might happen with the average sysadmin who speaks with servers all day and forgets that GUI exists. I brought this up just to see if it's reasonable to consider this specific use case.
No worries. You're not the first person to encounter this. If there's a way to get notified when the password changes using `passwd`, we can show a dialog prompting you to change your KWallet password to match it. I don't know whether this possibility exists, though. Do you happen to?
(In reply to Nate Graham from comment #3) > No worries. You're not the first person to encounter this. > > If there's a way to get notified when the password changes using `passwd`, > we can show a dialog prompting you to change your KWallet password to match > it. I don't know whether this possibility exists, though. Do you happen to? I bet my five cents that someone on Reddit's r/kde or r/archlinux will know about that.
I asked my smartest colleagues who pointed me at https://stackoverflow.com/a/10111728/2934226 and https://man.archlinux.org/man/pam_chauthtok.3.en. It's not clear how feasible it would be to use either of those to accomplish this, though.
(In reply to Nate Graham from comment #5) > I asked my smartest colleagues who pointed me at > https://stackoverflow.com/a/10111728/2934226 and > https://man.archlinux.org/man/pam_chauthtok.3.en. It's not clear how > feasible it would be to use either of those to accomplish this, though. I think that a scheduling the cron job to read changes to the 2nd field (encrypted password) of the /etc/shadow file seems feasible and safe, since it does not need the raw password. The only issue is adding the authentication engine to the shadow group so that it can read the file, since /etc/shadow has 640 permisson.
We wouldn't use a cronjob, we'd watch the file for changes directly. However reading the contents of the file would require a daemon with elevated privileges, which presents security challenges. In addition, we'd need to cache the old encrypted password to know when it changed to something else, presenting further security challenges. This is all sounding quite risky. At this point I'm going to say that I don't think the risks are worth the benefits. I'd be happy to be proven wrong if someone wanted to submit a patch to do it that was well-considered from a security angle. Thanks anyway for the idea!
(In reply to Nate Graham from comment #7) > We wouldn't use a cronjob, we'd watch the file for changes directly. However > reading the contents of the file would require a daemon with elevated > privileges, which presents security challenges. In addition, we'd need to > cache the old encrypted password to know when it changed to something else, > presenting further security challenges. > > This is all sounding quite risky. At this point I'm going to say that I > don't think the risks are worth the benefits. > > I'd be happy to be proven wrong if someone wanted to submit a patch to do it > that was well-considered from a security angle. > > Thanks anyway for the idea! You're welcome! I'm very glad to contribute :) Perhaps we wouldn't have to cache the encrypted password, just a hash might be enough. However, the daemon with elevated privileges can already be a no-go.