Version: (using KDE 4.1.1) OS: Linux Installed from: Unlisted Binary Package It's a fact that kwalletmanager can show every password stored in every open wallet. For common user it's unnecessary function, because everyone knows his passwords. However, it makes kwallet really convenient tool for people trying to read your passwords. When someone has phisical access to your computer he can easyly sleal all your passwords. Thanks to kwallet he even don't need to install any software on your computer. It's enough to wait for the moment when user go away from he's comeputer. The intruder clicks on kwalletmanager and if only the 'default' wallet is opened all passwords belong to him.
Well it's a matter of security really. If you don't lock your screen session when you go away, it's your responsibility. Still, forcing the user to provide his wallet password when he tries to open kwalletmanager shouldn't be that bad.
Requiring the wallet password each and every time you want to actually _display_ any passwords should be a must. Of course, there are still different attack vectors, but that is not a reason not to block the most obvious and easy one.
Currently not requiring a password while the wallet is open is by design. I understand your concerns and will think about providing an interface for what I'll call "pseudo-authentication" (that is ask for the password even if it's not needed). Thus I'll make this bug a wishlist item for now.
Perhaps someone could clarify the design decision. On the face of it, leaving the wallet unprotected is a huge security risk. One obvious example is that an administrator with root can simply kill the screen saver process to gain access to the desktop. At that point, they have access to all of the user's passwords, including ones for systems for which the administrator does not have root. A better security methodology would be to require the master password whenever the access granting dialog is presented. That way, an attacker cannot bring a separate application, grant access, and read all of the passwords. A special case can be implemented for kwalletmanager in which the granted access is never remembered. That way, opening the wallet in the manager always requires an access grant with master password. Can someone please update this to be a severe bug instead of a wishlist item? Security should always be a priority, especially with sensitive data such as user passwords.
CC'ing security@kde.org as per wstephenson's suggestion.
(In reply to comment #4) > Perhaps someone could clarify the design decision. On the face of it, leaving > the wallet unprotected is a huge security risk. One obvious example is that an > administrator with root can simply kill the screen saver process to gain access > to the desktop. At that point, they have access to all of the user's > passwords, including ones for systems for which the administrator does not have > root. I'm not aware of a method that could successfully prevent this. After all root has many possibilities to read a user's secrets: - ptrace kwalletd - rewrite kwalletd to dump all passwords to a file - listen to dbus communication Basically once a wallet is opened you can't prevent root from reading the passwords which are already stored in memory. Not storing passwords in memory basically negates what kwallet is there for as the user would have to enter the master password any time a password has to be read or written. > A better security methodology would be to require the master password whenever > the access granting dialog is presented. That way, an attacker cannot bring a > separate application, grant access, and read all of the passwords. A special > case can be implemented for kwalletmanager in which the granted access is never > remembered. That way, opening the wallet in the manager always requires an > access grant with master password. > > Can someone please update this to be a severe bug instead of a wishlist item? > Security should always be a priority, especially with sensitive data such as > user passwords. The problem you're mentioning here is that kwallet's acl system pretty much sucks, identifying applications by a self-chosen name and storing them inside an unprotected configuration file. Without a proper ACL system there's not much to do but implement "bogus security". KSecretService which I'm currently working on as a successor will be better in this and other security-related regards. The current plan is to get it released with KDE 4.6. Up to that point you should not leave your wallets open when you're not sitting in front of your PC.
(In reply to comment #6) > Up to that point you should not leave your wallets open when you're not sitting > in front of your PC. Personally, I agree with this. Using the wallet is a personal choice, not a requirement. By the same token, the user has some flexibility as to when the wallet is closed. In fact, comment #4 fails to take into account that one of the times when you can have the wallet automatically close is when the screen saver starts. As Michael stated, there are indeed other ways that someone with administrative access could get access to wallet information. I would argue that this doesn't make the whole thing insecure by design; rather it just provides some level of security instead of an ultimate level. And, as usual, you tradeoff security and convenience. If you're not trusting of those on your box with root when you step away from the computer, you can either not use wallet at all (but this will cause some apps to store passwords in plaintext in config files) or you can have it close when the screensaver starts + when the last application stops using it + after 1 minute in the config dialog, and/or you can right click the tray icon -> "Close All Wallets" when you leave you computer, or at any other time.
Guarding against root is not something most implementations take into account as root is, in fact, root. As you need to type your passwords to get them into kwallet (or copy the safe & open it), root can get at your passwords, in any case.
The root user can always install key loggers, kernel tracers, and any number of other security-compromising devices to obtain user passwords. However, in a business environment, the key is accountability. I'd like to at least lock the front door so that intrusions are more detectable. Otherwise, a desktop administrator could be tempted to casually peek at a user's passwords, where the chance of detection might discourage the act. I agree that no system can ever be fully secure. My opinion is that security must exist in layers, with each step requiring a little more effort. That way, compromises are more likely to be detected so that the user can take appropriate corrective action.
I definitely think that the wallet password should always be asked when a new application not previously allowed requires access to the wallet, and when kwalletmanager displays the passwords on the screen. I only trust some applications to access my passwords, and I trust them in part for not revealing the passwords without security. Of course if the wallet is already open some applications will have the password in memory (even if I hope than they are not stored in clear text), but the existence of a harder to exploit breach should definitely not be an excuse to leave an easier to exploit breach open. It would be like saying "anyway someone can watch your keyboard through you window with a spyglass and record your passwords", or "someone can threaten you and force you to reveal your passwords", "so using passwords is useless"... Security has always been "only" a matter of making things harder (and longer) to break. Of course I always lock my computer when I go away, except when I forget, except when I go peeing letting someone working on my computer... And last point, that's what Firefox and Thunderbird do, always asking the master password before revealing all the passwords.
This bug is a duplicate of 147873. Could somebody merge them (comments, votes)?
*** This bug has been marked as a duplicate of bug 147873 ***