Bug 147873

I agree completely.  The default behaviour is for your wallet to stay open until it is manually closed.  Potentially dangerous actions like viewing passwords in clear text and changing the master password should require re-authentication much the same way that most web services will "remember" you and allow you a certain level of access but then require you enter your password to access more dangerous features.

*** Bug 140825 has been marked as a duplicate of this bug. ***

*** Bug 149403 has been marked as a duplicate of this bug. ***

I would like to ask if somebody can please update this to be a severe bug instead of a wishlist item.  Security issues can seriously compromise the usage of kwallet.

*** Bug 171608 has been marked as a duplicate of this bug. ***

Bug 171608 has a lot more comments.

To make a long story short, this seems like a trivial change and it can only serve to increase security.

*** Bug 271479 has been marked as a duplicate of this bug. ***

*** Bug 314599 has been marked as a duplicate of this bug. ***

Hi!
Sorry for my English.

kwallet is totally unsecure while it is open.
Anyone, who has access to non-locked desktop with opened kwallet, can view, modify or export all stored passwords or even change the wallet's password, without knowledge the original one.
The wallet's password required be entered every time for view, modify or export stored passwords, change the wallet's password, etc. - it is absolutely essential for safe operation of the kwallet.
This is definitely a security problem and this problem is not solved for almost 6 years ...
Protect our passwords, please!

Eugeny is completely right. Kwallet might as well store passwords in plain text on the desktop in a file called "passwords!.txt". Disabling kwallet is fairly easy, but it's super inconvenient having to re-enter passwords for akonadi, network manager, etc. every time it requests them. So you're stuck with security + inconvenience, or insecurity + convenience. I've happened to go grudgingly with the latter, but I wish this GAPING security flaw would get addressed VERY soon.

I'll add a new feature related to this report: ask for the current password upon password change request.

For the other problems, have ever tried the option named "close when unused for:" one can find in kwallet settings? AFAICT, that would fix all of the other concerns reported here.

(In reply to comment #11)
> I'll add a new feature related to this report: ask for the current password
> upon password change request.
> 
> For the other problems, have ever tried the option named "close when unused
> for:" one can find in kwallet settings? AFAICT, that would fix all of the
> other concerns reported here.

Yes, it is possible to set "close when unused for:" = 1 minute. Why use kwallet at all if you have to enter kwallet's password again and again and again all the time?
There is 2 type of actions: an usual everyday usage (to save/get password in kwallet) and the hazardous rare one (to view/export/import all passwords, change master password, etc.).
The comfortable usual everyday usage is to not enter kwallet's password every N minutes.
On the any hazardous actions kwallet MUST ask for password.
Just do it as option, please.
Sorry for my English.

Hi!

I'm also much concerned by the fact that if I ever forgot to lock my screen when leaving my computer, anybody could come and have access to all my passwords... Yet, closing the wallet every XX minutes would reveal very much annoying!

I think asking for the password again before displaying anything in plain would be much relevant.

To illustrate, I think Firefox's GUI policy about password (not mentioning encryption, or anything, just the interface) is relevant here: FF asks for the Master password in order to start the password manager, and then ask for the same Master password again if you are going to display the passwords.

It does make sense to assume that nothing ever guarantee that the person who entered the Master Password the first time (which may be quite a long time ago) is the person trying to display the passwords now, doesn't it?

I think, it's unacceptable and dangerous, that passwords can be read unconditionally in clear text, if the wallet is unlocked. I think, we need 3 states:

1) locked wallet
2) unlocked wallet: applications can access user/password information, but password will not be shown
3) unlocked wallet with visible passwords: applications can access user/password information, and passwords can be shown

One problem remains: How can I switch between 2 and 3. Entering a password twice (for state 1 and state 2) and switching back to state 3 after an timeout can be annoying for users, who need to copy-and-paste password from kwalletmanager to other applications. My idea: there should be options to configure this behavior.

Created attachment 93706 [details]
kwalltermanager-4.14.3-kauth.patch

This is especially problematic if you use the kwallet-pam PAM integration module as the wallet is always open. This patch adds kauth policies (polkit) for viewing the passwords, exporting the wallet to XML, and changing the wallet password with default set to ask for password before performing any of these. It's not hard to get kwalletd to give the plaintext password but this will protect from the average user on the scenario described by the OP.

I've also made a patched ebuild for gentoo: https://github.com/fernando-rodriguez/portage-overlay/tree/master/kde-apps/kwalletmanager

Created attachment 93719 [details]
kwalletmanager-4.14.3-kauth.patch

Updated patch to also authenticate before showing Maps.
Note that this patch asks for your user password, not wallet password as suggested by bug report. I think that makes more sense and it allows us to use kauth/polkit so it's user configurable.
Also note that by default it asks for password everytime you look at a password or map, but this is configurable through PolicyKit (or whatever kauth backend is). To set it to ask for password once per session with PolicyKit copy /usr/share/polkit-1/actions/org.kde.kwallet.policy to /etc/polkit-1/actions and change <allow_active>auth_self</allow_active> to <allow_active>auth_self_keep</allow_active>. The location of these files may vary among distros.

Created attachment 93839 [details]
kwalletmanager-4.14.3-kauth.patch

Updated patch again. I'd missed that you could copy password to clipboard by right-clicking on the entry.

(In reply to Fernando Rodriguez from comment #17)
> Created attachment 93839 [details]
> kwalletmanager-4.14.3-kauth.patch
> 
> Updated patch again. I'd missed that you could copy password to clipboard by
> right-clicking on the entry.

I completely switched to latest KF5-based KDE applications so I cannot test this myself.
On what platform are you testing your changes? I may eventually build an equivalent docker image.

I'm using KDE 4.14.8 on Gentoo.
I made some more changes last night. I need to test thoroughly and will post an updated patch probably tonight. Now I have three policies, view, modify, and change password and they cover every action you can take on kwalletmanager except closing wallets. That may be excessive for most but you can ship a permissive policy by default and users needing the extra security can just update the policy. When used along with a strong MAC policy it makes it possible to keep the wallet data fairly secure even when the wallet is always open.

*** Bug 450004 has been marked as a duplicate of this bug. ***

Some of this has been said before, but see Bug 450004 comment 4, for those who are still concerned.
TL;DR: Just hiding the passwords visually adds little real security (see the linked comment for details). There are better solutions, but as always, it's a trade-off between security and convenience.

I would agree that changing the master password should require re-entry of the current one.

(In reply to michaelk83 from comment #21)
> Some of this has been said before, but see Bug 450004 comment 4, for those
> who are still concerned.
> TL;DR: Just hiding the passwords visually adds little real security (see the
> linked comment for details). There are better solutions, but as always, it's
> a trade-off between security and convenience.
> 
> I would agree that changing the master password should require re-entry of
> the current one.

I just don’t understand this attitude. The fact that a person can bypass most UI-based security with some effort and access to an unlocked system isn’t a good reason to forgo all such security. I lock my car at night even though a thief could easily break the window or open the door with a coat hanger. The odds are better that the person you let use your computer to check their email is mildly nosy than really motivated.

I left comment #2 in 2007. I have a little experience with Linux. But I couldn’t pull off any of these “trivial exploits” without some time to think about it. However, I can click “Show Passwords” with the best of them (as can the worst of them).

(In reply to kilrae from comment #22)
> I have a little experience with Linux. But I couldn’t pull off any of these
> “trivial exploits” without some time to think about it. However, I can click
> “Show Passwords” with the best of them (as can the worst of them).
It is true that most security people and most devs forget that most users are far less technical than them. But it is still also true that merely hiding the passwords visually, encourages bad security practices by giving a false sense of security. It offers no real protection, except against the very simplest of attacks (or curiosity).

If *not* asking for a password when revealing the plain text of an unlocked wallet, encourages the common user to learn and apply better security practices (to lock your session when you leave the PC, to not leave your wallet unlocked when you don't need it, etc), then that's a small win for the security community. In the end, such practices will protect you better, both from the simple attacks, and from more serious ones.

> The odds are better that the person you let use your computer to
> check their email is mildly nosy than really motivated.
If that is really a concern, the proper practice here is to create a separate guest user for them. They can have their own wallet there, with their own passwords, and they can look at those passwords in plain text all they want. Yours will still be protected.

*** Bug 470676 has been marked as a duplicate of this bug. ***

(In reply to michaelk83 from comment #23)
>If *not* asking for a password when revealing the plain text of an unlocked wallet, encourages the common user to learn and apply better security practices (to lock your session when you leave the PC, to not leave your wallet unlocked when you don't need it, etc), then that's a small win for the security community.

It implies that we  leave alone, or that we never run a process that we don't want to run locked when other people are areound, or just we never mistakenly forget to lock our pc etc.

If 99% of passwords manager require the main password to be typed, I don't think that we should ignore their views on this situation and think that we have the right judgment here.

Firefox password manager has it, windows credentials manager has it, why not on Linux?

> Firefox password manager has it, windows credentials manager has it, why not
> on Linux?
100%AGREE

I wonder about this 16-year discussion without any action.

This is definitely a security issue that has to be resolved asap.