17

This was really bred from another suggestion, but it's not exactly the same suggestion so I'm posting it as a different one.

Currently, there's a problem with KWallet: some people want it to open automatically at log-in so that they don't have to enter 2 different passwords 3 different times. Some people think this is an important part of its security. I want to be able to have the wallet close after the last application uses it, after 1 minute or after the screensaver starts (whichever comes first), but if I set it like that and have the Twitter plasmoid on the desktop, then I get bugged every 5 minutes to open it again.

Then I discovered this beauty:

I figured I might be able to change the settings with a right-click or a drop-down menu or something... but I couldn't.

... but it's genius!
Change the, "Always Allow" bit to a drop-down menu that contains the following options:
Open without prompting;
Open, use and close without prompting;
Always Allow when open;
Allow and close when open;
Prompt every time;
Deny every time (this option would require you to manually type your password into the application every time, e.g. logging into kopete).

You've got application-specific settings so you can decide which applications need the most security, how much security applications have and so I don't get pestered by Plasma every 5 minutes. Everyone gets exactly what they want - and more, I think. It looks like a win-win-type implementation.

Oh pleaseopleaseopleaseoplease!

Please note that this would require having KWallet already know your password, in order for it to open your Wallet to access the information requested. Therefore this defeats the security of the current system, as the needed password to decrypt the wallet would be stored in memory.

How did I know this was a, "Not as easy as it looks" feature...? >.<'

Couldn't it be tied in with pam so that it uses your login password to decrypt your wallet?

Something else that could be considered: when the wallet is first needed, have the user open it. Then, any application set to, "Open without prompting" doesn't actually open the wallet - instead, when the wallet is first opened, it gets the password from the wallet and stores it in a text file in /tmp/kde-[user]. For example, if I set Plasma and Kopete to, "Open without prompting", then when Plasma asks for my wallet password on log-in then both the Plasma and Kopete passwords are stored in /tmp/kde-[user] and read from there instead. These files are removed on logout. Then, when the wallet closes and Konqueror asks for my bank details, it obviously *definitely* asks for my wallet password, because THOSE details aren't stored in /tmp/kde-[user].

I dunno, maybe I'm making this too complex.

Using a text file for any password is a bad idea. At the very least it should be an encrypted file.

Well, yes, the text file was just an example.

KDE already has a text encrypting system builtin as part of KConfig, however it can be easily defeated because the Key is publicly available as part of the KDE sources.

bcooksley wrote:KDE already has a text encrypting system builtin as part of KConfig, however it can be easily defeated because the Key is publicly available as part of the KDE sources.

Is there really a point in having it then?

Yes, since it presents a barrier which will stop the casual person just sneaking a look at the configuration file.
Might even stop someone who doesn't know where to get the key from.

About security... try capture data from the dbus user session, and you'll find that password travel there in cleartext. If I download a program that runs with my priviledges it can easily look for calls to kwalletd and mail them.
Try this at the console.

dbus-monitor --session > log
# now, open a program that requests data from kwallet.
CTRL-C
grep -A 10 readPassword log
# Whoops.

Another thing: I've been told that kwallet really don't checks what application is querying it. Kwallet is fully satisfied with the applications name as identifier, which sould make it easy to impersonate another program. Kwallet at least could "reach out" and do a hash of the executable of the requesting program.... And then I don't know how easy it is to impersonate in the dbus-system.

I'm starting to hate kwallet. What's the reason for giving a sense of false security and security by obscurity, it's worse than not having kwallet at all.

It isn't giving a sense of Security by Obscurity, because the protection it provides is in the encryption of the passwords when they are in the wallet. I agree though that the passing of the passwords should probably be hardened to avoid sniffing passwords.

Applications could "Register" with KWallet on startup, and recieve an "Authentication" key that could be used to decrypt the passwords. This would ensure that only the application could recieve passwords meant for it, transferring this key without others being able to recieve it would be the only problem.

bcooksley wrote:It isn't giving a sense of Security by Obscurity, because the protection it provides is in the encryption of the passwords when they are in the wallet. I agree though that the passing of the passwords should probably be hardened to avoid sniffing passwords.

Applications could "Register" with KWallet on startup, and recieve an "Authentication" key that could be used to decrypt the passwords. This would ensure that only the application could recieve passwords meant for it, transferring this key without others being able to recieve it would be the only problem.

How would you prevent anyone from sniffing the key exchange? It's hard (impossible?) to achive security when all the critical processes are run as the same user....

If it could be done, I would vote for it.

What about a kwallet server run as root (or at least some other user), starting when the first user logs in? (and then you key exchange idea)

Running as a different user wouldn't help. The best way would probably to use some form of a system like SSL, which would be part of the registration process, which would be the only way to truly be secure.