Bug 92845 - KWallet should use PAM to make single-sign-on possible
Summary: KWallet should use PAM to make single-sign-on possible
Status: RESOLVED FIXED
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: kwallet (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
: 102465 114662 143687 184537 197788 210726 291933 307396 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-11-07 13:06 UTC by Steffen Weber
Modified: 2015-07-27 13:32 UTC (History)
87 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Adds pam_kwallet support to startkde (691 bytes, patch)
2014-04-25 19:58 UTC, Herbert Graeber
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Steffen Weber 2004-11-07 13:06:20 UTC
Version:            (using KDE KDE 3.3.1)
Installed from:    Gentoo Packages
OS:                Linux

It should be possible to use PAM with KWallet. This way I think a secure single-sign-on could be made possible by using the PAM module pam_ssh. You´d have to setup your /etc/pam.d/system-auth file to use pam_ssh as an alternative to pam_unix. Then you are able to login to your computer by entering the passphrase of your private key in ~/.ssh/.

The thing that make single-sign-on possible is that pam_ssh automatically launches the ssh-agent tool (belongs to OpenSSH) so that you´ll never have to enter your private key´s passphrase again when it is needed for example by KWallet.

I do not understand more about this topic than I´ve written down here, but I think it might satisfy the wish for a passwordless KWallet without of making it stupidly insecure.
Comment 1 Yves Glodt 2004-11-08 19:36:32 UTC
*** This bug has been confirmed by popular vote. ***
Comment 2 _ 2005-01-02 20:26:34 UTC
Something similiar could also be done by storing the user's password in the wallet, and then have KDM silently login to the wallet (user clicks his user, and instead of account password types the wallet password) to get the linux password and log in with that.
Comment 3 Jonny Heggheim 2005-01-18 17:10:47 UTC
Would be nice to integrate KDM and KWallet!
Comment 4 Gilles Schintgen 2005-02-11 15:19:52 UTC
Just in case this gets implemented (and I really hope so...), I'd like to point out that it should be implemented in such a way as to be compatible with pam_mount. Currently I'm using an encrypted home partition that is mounted automatically at login by pam_mount (using the login password). Using information from the user's home could be problematic when it's not yet mounted. So, please consider this point.
It would just be too cool to have single-sign-on for the system login, pam_mount and kwallet. Thanks for listening :-)
Comment 5 Leo Savernik 2005-02-11 18:14:34 UTC
I'd like to have single-sign-on also working with the default login password. Please also keep in mind that not all people use kdm as their login manager (or no login manager at all! Runlevel 3, need I say more? ;-) ), so it should not depend on kdm or any graphical login procedure.
Comment 6 Tiago Freire 2005-02-25 12:51:47 UTC
what would have to happen then? will kwallet become a frontend/gui for the 'wallet' cli app, being useable without qt , kde or anything, and wallet would be a base system / libs for ppl to store their many passwords, possibly with bindings for other languages to use it, hopefully with Mozilla, Gnome, Freedesktop.org and possibly other ppl cooperation, so that we can have a solution which is not kde specific, but which encompasses the whole desktop? Maybe it should be talked with other parties which may be interested in the subject. Maybe I am overly optimistic, but I think this would be the best thing possible to happen: a unified wallet system with single sign-on useable by any desktop environment, so that I can use any desktop without having to retype the passwords in mozilla, konqueror, or foo. 
Comment 7 Josiah Ritchie 2005-08-28 20:16:26 UTC
I'm investigating this for the community over at LinuxBiometrics.com. We have talked a bit about how to most effectively integrate biometrics and so I'm investigating. We already have work building a PAM bridge and so Kwallet's attachment to PAM would significantly ease the efforts that would need to be made.

Just wanted to share that we see this as being a beneficial direction for our needs also. :-)
Comment 8 Roland Schulz 2005-09-11 16:34:27 UTC
*** Bug 102465 has been marked as a duplicate of this bug. ***
Comment 9 Roland Schulz 2005-09-11 17:25:00 UTC
Wouldn't be a kwallet pam module possible? It would start kwallet as soon as one logs in. This way it works also for other types of logins (NX, console, xdm,..) and doens't relay on ssh.

Of course an auto login to kwallet isn't much safer than a kwallet without password, but it adds an extra little bit of security (e.g. secure as long as you don't log in) at no cost for the user. So I think it should be possible.
Comment 10 Gilles Schintgen 2005-09-17 20:40:37 UTC
If I understand the following page correctly something similar already exists for Gnome:
http://www.flyn.org/projects/pam_keyring/index.html
Comment 11 Bernie Innocenti 2005-09-18 02:19:57 UTC
In reply to comment #10 (Gilles Schintgen):

> If I understand the following page correctly something similar already exists for Gnome:
> http://www.flyn.org/projects/pam_keyring/index.html 

This looks exactly what we need for KWallet.
Comment 12 Leo Savernik 2005-09-18 10:12:56 UTC
> http://www.flyn.org/projects/pam_keyring/index.html 
 
And it's abandoned, so we can take it over any time :-)
Comment 13 Roland Schulz 2005-09-18 11:02:41 UTC
Gnome hat it and Mac OS x has it too: http://developer.apple.com/documentation/Security/Conceptual/keychainServConcepts/02concepts/chapter_2_section_1.html

So we need it, also! ;-)

The first step we need, is a seperation of the daemon and the gui. Like gnome does it (gnome keychain daemon/manager). Otherwise the pam module can't start the daemon because of the gui dependance. Should this be an own feature request?
Comment 14 George Staikos 2005-09-18 14:39:38 UTC
On Sunday 18 September 2005 05:02, Roland Schulz wrote:
> Gnome hat it and Mac OS x has it too:
> http://developer.apple.com/documentation/Security/Conceptual/keychainServCo
>ncepts/02concepts/chapter_2_section_1.html
>
> So we need it, also! ;-)
>
> The first step we need, is a seperation of the daemon and the gui. Like
> gnome does it (gnome keychain daemon/manager). Otherwise the pam module
> can't start the daemon because of the gui dependance. Should this be an own
> feature request?


   Right now the whole thing is very dependent on Qt and actually DCOP.  Once 
KDE4 development really starts (ie: technology changes in kdelibs begin), 
this can be considered.
Comment 15 Tiago Freire 2005-09-18 17:48:15 UTC
Personally, I think teh Best Way Possible® it to get in touch with Freedesktop.org and Gnome people too, and draft a standard way to do it, place under teh Freedesktop.org umbrella. You know, avoiding the NIHS (Not-Invented Here Syndrome), and doing something which can benefit all, instead of something KDE-centric. AFAIK tehre are already 'standards', at least in draft form, for things like DE-agnostic themes, clipboard, and so on. This could be one more thing.
Comment 16 George Staikos 2005-09-19 00:30:09 UTC
On Sunday 18 September 2005 11:48, Tiago Freire wrote:
> ------- Personally, I think teh Best Way Possible® it to get in touch with
> Freedesktop.org and Gnome people too, and draft a standard way to do it,
> place under teh Freedesktop.org umbrella. You know, avoiding the NIHS
> (Not-Invented Here Syndrome), and doing something which can benefit all,
> instead of something KDE-centric.


  If there was interest on that side, why didn't they come to us and say they 
wanted to co-operate too?  KWallet is quite old and I've never seen or heard 
of something similar on Linux or Gnome.

  That being said, the file format is open and there is a chance to extract 
the daemon outside of KDE startup now that dbus is a likely candidate for 
KDE4.  I don't have any interest in redesigning and reimplementing all of 
KWallet though.  It works, and there are many other things that need to be 
done in KDE4.
Comment 17 Leo Savernik 2005-09-19 16:16:02 UTC
Am Montag, 19. September 2005 00:30 schrieb George Staikos:
>   If there was interest on that side, why didn't they come to us and say
> they wanted to co-operate too?  KWallet is quite old and I've never seen or
> heard of something similar on Linux or Gnome.


Right you are. It's about time that Gnome incorporates some precedent set by 
KDE.
Comment 18 George Staikos 2005-09-19 21:44:28 UTC
On Monday 19 September 2005 10:16, Leo Savernik wrote:
> Am Montag, 19. September 2005 00:30 schrieb George Staikos:
> >   If there was interest on that side, why didn't they come to us and say
> > they wanted to co-operate too?  KWallet is quite old and I've never seen
> > or heard of something similar on Linux or Gnome.
>
> Right you are. It's about time that Gnome incorporates some precedent set
> by KDE.


  That's not true either. They have and do (see freedesktop).  I just don't 
buy this argument that KWallet was done at the preclusion of Gnome.  It 
preceded any other similar project that I could find at the time.
Comment 19 Tiago Freire 2005-09-21 13:30:31 UTC
There are several standards, in draft form or otherwise, being developed or promoted for adoption on freedesktop.org. The 'Single' bit of 'Single Sign-On' only holds completely true if it works on every application. If you only use KDE apps, fine, but I find thinking like this a bit selfish (and I am not implying it is your thinking, just stating my belief). Ithink it is really worth pushing forward the 'Single' part of this idea, and have filed a project-request-bug at freedesktop.org.
https://bugs.freedesktop.org/show_bug.cgi?id=4513
Comment 20 Musta Vuohi 2005-10-28 04:01:11 UTC
Uh. It would be awesome to use pam_usb (http://www.pamusb.com) with KWallet, too.
Comment 21 George Staikos 2005-11-15 05:14:44 UTC
*** Bug 114662 has been marked as a duplicate of this bug. ***
Comment 22 michael papet 2006-01-31 23:32:40 UTC
Absolutely fantastic idea.  I vote with 20 points!
Comment 23 Mathieu Jobin 2006-04-13 07:32:28 UTC
it is really required to have this done using PAM ? I'm don't know. But the basic idea of having the kwallet automatically open upon login is strongly wished and I really wish to see this feature in the next release of KDE.

thanks

Comment 24 Andrei Slavoiu 2006-04-13 15:16:45 UTC
Actualy I think it would be possible using Kwallet integration in KDM. So that the account password is stored inside the wallet, and at logon time you just enter the password for the wallet. What do you think?
Comment 25 P. Varet 2006-04-13 15:22:28 UTC
Hi Andrei,

This would be excellent, yes! Do you think it is possible technically?

Thanks!
Comment 26 Gilles Schintgen 2006-04-13 15:30:43 UTC
> Actualy I think it would be possible using Kwallet integration in
> KDM. So that the account password is stored inside the wallet, and at logon
> time you just enter the password for the wallet. What do you think?

No, the account password should always be the one stored in /etc/shadow. 
Everything else would be incoherent. In my opinion, having the login password 
depend on how you login (login, ssh, kdm) would be a terrible idea.

The password entered into kdm can already be reused by other PAM modules, such 
as pam_mount. kwallet could "simply" integrate with PAM and obtain the 
password in the same way.

The kwallet password would then be your login password. If the login password 
is changed, decrypting of the wallet will fail and kwallet would inform the 
user about it and ask for the old password in order to reencrypt the wallet 
with the new password.

What do you think about this idea?
Comment 27 P. Varet 2006-04-13 16:03:50 UTC
With my apologies, Gilles, I think I disagree with your judgment on authentication sources: the whole point of pluggable authentication modules (P.A.M. :)) is precisely to let you authenticate yourself from different possible sources. I am not sure what invalidates KWallet as one such source, but I might be overlooking something, of course.

However, would it be possible to simply encrypt the KWallet password using the user's login password? This way, when the user logs in, he uses his regular login password; that password is also used to unlock his KWallet password, and KWallet is then loaded as usual.

Would PAM allow for such a behavior? This way, it would respect Gilles' misgivings about the previously suggested behavior, while still allowing for KWallet to be opened automatically at login time, and still allowing for different login and KWallet passwords.

What do you think?
Comment 28 Gilles Schintgen 2006-04-13 16:22:04 UTC
> With my apologies, Gilles [...]

I'm sorry if my response sounded a bit harsh, it really wasn't intended that 
way.

> However, would it be possible to simply encrypt the KWallet password using
> the user's login password? This way, when the user logs in, he uses his
> regular login password; that password is also used to unlock his KWallet
> password, and KWallet is then loaded as usual.

There's a second reason I don't like this behaviour: I'm using an encrypted 
home partition which is automatically decrypted by pam_mount using my login 
password. Since the KWallet data is stored inside this partition I don't see 
how this scheme could be implemented without breaking this kind of setup. 
This same problem also arises for people using pam_mount to mount a remote 
home directory. Unfortunately kdm can't rely on (or at least it shouldn't) 
the availability of the KWallet data before the user is authenticated by PAM.
Except, of course, if the KWallet were to be stored outside the user's home 
directory which, I think, would be a bad idea.

Kind regards,

Gilles
Comment 29 michael papet 2006-04-14 03:22:57 UTC
> This way, when the user logs in, he uses 
> his regular login password; that password is also used to unlock his 
> KWallet password, and KWallet is then loaded as usual.

I'm not sure about this.  This creates a what looks like a bad scenario where kwallet-stored passwords are available upon request once a user is logged in.  Well, what if I'm a bad guy and somehow get access to your desktop?  I think my first stop is kwallet.  It's open right?

Personally, it doesn't bother me that kwallet asks for a password upon opening after I'm into my desktop.  

Below the gui level, PAM and kwallet must remain separate.  The kwallet gui needs to make it appear something like a single wallet though.
Comment 30 Jesse Litton 2006-04-14 04:59:09 UTC
> Well, what if I'm a bad guy and somehow get access to your desktop?

Then I should have locked my desktop.

My second act, as a bad guy, is to change your desktop background to a picture of Tom Welling with his shirt off.  Very few people around my office forget to lock their desktop anymore.
Comment 31 P. Varet 2006-04-14 10:07:25 UTC
Gilles,

Please note that in my last proposal, to my knowledge, KWallet could be opened only after everything else has been unlocked, i.e. after the login process has begun and the home partition has been mounted, in the same way that your home partition is only mounted after your authentication credentials have been validated. So your setup would not be prevented from working. If I'm not wrong in this and what I'm suggesting is indeed possible, would the proposal satisfy you?


Michael,

Would this be different from the usual way KWallet works? Once your KWallet is opened, some Bad Guy sneaking his way to your desk can access its passwords as well. The only difference would be that at login time -- when you're known to be at your desk -- the KWallet would be loaded as usual, simply without asking for its own password. But you raise a good point, and the unlocking of KWallet at login time should be an option. Perhaps it is worth pointing out that, as things currently stand, many users choose to use no password at all for their KWallet -- incidentally storing all its passwords in clear text -- so as to avoid the annoyance of unlocking it manually at login time. Our proposal ideas here would be a significant step up from that behavior in terms of security.

With kind regards,

-- S.
Comment 32 Gilles Schintgen 2006-04-14 12:35:13 UTC
> Please note that in my last proposal, to my knowledge, KWallet could be
> opened only after everything else has been unlocked, i.e. after the login
> process has begun and the home partition has been mounted

Now I see that I've misread your last proposal:
> However, would it be possible to simply encrypt the KWallet password using
> the user's login password? This way, when the user logs in, he uses his
> regular login password; that password is also used to unlock his KWallet
> password, and KWallet is then loaded as usual.

I thought it was the same proposal as before, except that now the two 
passwords are the same. In other words I interpreted "he uses his regular 
login password" as "he types the same password as always but it's first used 
to open the wallet in order to retrieve the account password".

> would the proposal satisfy you?

Yes, it would be fine (for me). The only difference to my proposal is that 
KWallet doesn't get the password through PAM, but directly from kdm. My 
proposal would also work with console logins (but I'm not sure this would be 
desirable) and with xdm and gdm.
Since I'm mostly using kdm, I'm not going to insist on this. (And I don't know 
how difficult it would be to properly implement the PAM integration.)

In the long term I'd prefer a desktop-independent approach, as already pointed 
out in comment #19.

Regards,

Gilles
Comment 33 Mathieu Jobin 2006-04-14 17:05:21 UTC
I am not convinced of the PAM thing in this case. I beleive comment #27 is saying about same thing as me and I totally agree with sundance. lets not change to much and just use the password from kdm to open the wallet.

actually, if I understand the PAM idea, It's totally different and would serve a totally different purpose. I think people are fighting for a different egg.
Comment 34 Andrei Slavoiu 2006-04-16 08:42:00 UTC
> No, the account password should always be the one stored in /etc/shadow.
> Everything else would be incoherent. In my opinion, having the login password 
> depend on how you login (login, ssh, kdm) would be a terrible idea.
Well, of course the password from /etc/shadow (or NIS, whatever is used by the system) will be used to actualy authenticate the user, I was just suggesting that instead of typing the password in KDM it could be taken from the wallet.

> The password entered into kdm can already be reused by other PAM modules,
> such as pam_mount. kwallet could "simply" integrate with PAM and obtain the
> password in the same way.
Not everybody uses PAM, it is possible to configure a system to autenticate directly from /etc/shadow.

> The kwallet password would then be your login password. If the login password
> is changed, decrypting of the wallet will fail and kwallet would inform the
> user about it and ask for the old password in order to reencrypt the wallet
> with the new password.
Probably not everybody likes to have the same password for the account and wallet (the account password could get compromised easier then the wallet since it might also be used remotely).

> There's a second reason I don't like this behaviour: I'm using an encrypted
> home partition which is automatically decrypted by pam_mount using my login
> password. Since the KWallet data is stored inside this partition I don't see
> how this scheme could be implemented without breaking this kind of setup.
With this you are right, I didn't consider this kind of setup. But I suppose you could just encrypt a subdirectory with your personal stuff, not the entire home.
Comment 35 Chris Kerr 2006-04-16 10:22:32 UTC
> There's a second reason I don't like this behaviour: I'm using an encrypted 
 > home partition which is automatically decrypted by pam_mount using my login 
 > password. Since the KWallet data is stored inside this partition I don't see 
 > how this scheme could be implemented without breaking this kind of setup. 

Perhaps there could be a backup/failsafe option to keep the old way of doing things for setups like this.
In any case - if you have an encrypted /home, surely you don't actually need to encrypt the kwallet file (although admittedly you would need to if /home was network mounted and needed your account password)
Comment 36 Julien Bigot 2006-06-14 19:13:42 UTC
why not have a crypted loop device containing a file with passwords stored in it (no need to change current KWallet config file layout)?
This way, you could either mount this device at login, with pam_mount or mount it every time KWallet is used (depending on user settings).
This should of course be done transparently to the user.
The KWallet password would then be the same as the user password, but is this a problem ? If it is, the filesystem could be crypted with a different password, disabling the auto mount option.
The only drawback I see to this approach is on systems different from linux ...
Comment 37 Peter Fischer 2006-11-01 13:54:55 UTC
addition to #10, #11, #12:
PAM_KEYRING for GNOME is not dead any more:
http://www.hekanetworks.com/index.php/publisher/articleview/frmArticleID/25/staticId/31/

Personally, I'd like to see a modular, pluggable (multiplatform) solution using pam.

Currently I'm using pam_ssh, keychain etc. for firing up gpg and ssh agents for my entire KDE session, which saves me a lot of "enter passphrase here"/"enter passphrase there" and works like a charm, I'm using fish:// URLs very often.

That is, as long as I don't change my password/passphrases too often...

It would be cool to have a wallet/keyring opened by some pam_module, and see (at least all FOSS )browsers, IMs, VoIPs etc use it seamlessly.

If that framework could perform password/passphrase change transactions, I'd feel like in heaven.


Comment 38 Andreas Bayer 2006-11-09 13:36:53 UTC
There are ssh-agent and gpg-agent. 

So bring up a third agent for wallets(kde), keyrings(gnome) and passwords(firefox).

This third agent should use kwallet as gui and have a libpam_wallet for single-sign-on.

Perhaps this agent could also start the other two (ssh and gpg) and provide them the passphrases.
Comment 39 Oswald Buddenhagen 2007-04-01 09:14:21 UTC
*** Bug 143687 has been marked as a duplicate of this bug. ***
Comment 40 Aaron Mulder 2007-04-10 16:30:22 UTC
I'm currently using a laptop with openSUSE, KDE, and a fingerprint reader (via PAM).  The behavior I have now is that from KDM, I swipe my finger to login.  Then, KWallet immediately prompts me for a password, because KNetworkManager stores my wireless keys in KWallet and 99% of time I login (home, work) there's a secure wireless network there to connect to.  So in total, I have to swipe my finger and then enter a password, which is bothersome.

In this situation, I am required to open KWallet as soon as I login (on account of KNetworkManager), so it would not bother me if the wallet was automatically opened upon login.  If a bad guy steals my laptop while I'm logged in, my wallet will almost surely be open as is.

I guess I'm looking for the outcome to be one of these:
 * I swipe my finger once to log in, the wallet is automatically opened, and I don't have to take any additional action.
 * I swipe my finger once to log in, and then again to open the wallet, but at least no password entry is required.  This may mean that KWallet uses the fingerprint reader via PAM to unlock the wallet, or it may mean that KNetworkManager stops using KWallet for storage and instead uses some other mechanism that in turn uses the fingerprint reader via PAM to access the wireless keys.

I will note that I would be far less concerned about this if KNetworkManager did not use KWallet, but since I'm so reliant on secure wireless networks, I'm therefore reliant on KWallet.
Comment 41 Ryan Neufeld 2007-04-10 17:41:39 UTC
RE: Comment #40

I have a similar issue on my machine; having to swipe my finger to get into KDE and then having to enter my password after.

While I see the benefits of not having PAM integration in KWallet, I can also see the benefit to making it an *option* to use pam for authentication; at least then by default it can be configured to use what it uses noe. 
Comment 42 Roland Schulz 2007-04-10 18:32:39 UTC
Do those finger print sensors send some kind of password computed from the finger profile or just a yes/no? In the later case there is no way you could safe unlock the wallet with it, because without a password you can't unencrypt.
Comment 43 Aaron Mulder 2007-04-10 18:57:06 UTC
I don't know enough about the BioAPI and related stuff to say for sure, but I don't believe the fingerprint reader stores a password.  I think it's just a yes/no (based on the fact that I don't remember needing to type a password for it to remember when I first saved the fingerprint profile).  Perhaps Josiah Ritchie (Comment #7) could say more.

However, the user account in question still *has* a password.  I'm not sure whether there's some way to retrieve it if you've successfully authenticated some other way.  Or maybe the fingerprint reader returns some data on the finger geometry or something that could be used as a "password" to unencrypt.  Or, maybe the fingerprint reader can be coerced to save some data along with the fingerprint profile and return that to use as a decrypt key.  Hopefully someone who knows more about the biometric plumbing will speak up.  :)
Comment 44 Ryan Neufeld 2007-04-10 19:09:26 UTC
The fingerprint scanners do not in fact store a password. Instead it store some information about the users fingerprint.

The primary problem here seems to be the encryption of the passwords. I wonder if a system similar to how the LUKS cryptfs works. Essentially you can have multiple keys for an encrypted partition, which in turn decrypt the real key.

Perhaps to get the pam side of it working the user would have to run a configuration program and effectively "train" KWallet to use the information provided by PAM.

I am not an expert in any way with PAM, but I do know that it is very flexible.

Regardless of how one would get the fingerprint scanner to work, if KWallet worked with PAM, then the biometrics would work as well as they are just a PAM module.
Comment 45 Roland Schulz 2007-04-10 19:36:17 UTC
> Regardless of how one would get the fingerprint scanner to work, if KWallet 
> worked with PAM, then the biometrics would work as well as they are just a PAM 
> module. 

Not quite. If the biometrics pam module doesn't provide a password, Kwallet won't be able to encrypt.
Comment 46 Jörg Hermsdorf 2007-04-16 12:53:36 UTC
I have a T60p ThinkPad with integrated fingerprint reader using libthinkfinger for authentication. For simplicity, I would like to use my fingerprints to open KWallet too, but I don't think this will ever be possible:

If you want to encrypt someting, you need some kind of secret to feed the encryption algorithm. If you just swipe your finger, the only secret you can supply is your fingerprint. Fingerprints may be OK for authentication but not for encryption. In Germany for instance, every citizen has to deposit all their 10 fingerprints to get a new ID-Card by the end of this year, so fingerprints can't be considered a secret any longer. Even if the bioapi/libthinkfinger libraries would return some kind of password, it would be insecure because this password generator has to be deterministic. So everybody who knows your fingerprints could generate the password, too.
The only way I see, to provide some kind of secret using fingerprints, is a series of fingerprint scans with the different fingers of your hand. The order of the fingers you use is the secret. But I don't think this could be seriously considered secure, because brute-force attacks would success within a second, unless you require the user to provide a series of 200 fingerscans or so ;)
And I think it's even faster to type in your KWallet password than swiping your fingers 10 times or even just 4 times.

So from my point of view, there are just two options:
- Disable encryption in KWallet, so no password/fingerprint/whatever is required by the user (not even for authentication, because he is already authenticated), and hope that nobody can access your KWallet files.
- Live with the fact, that KWallet requires a password to encrypt your stuff.
- (Wait for the first open-source/open-design brain-computer interfaces ;))
Comment 47 Martin Flöser 2007-08-05 18:56:50 UTC
I really like the idea of using PAM. At the moment I use pamusb and I still have to type in my password to open kwallet (which happens at every startup because of kopete connecting to the net). Sometimes it gets really annoying. It would be great to have some kind of single-sign-on-system which also integrates Mozilla or other open source software.
Just an idea: why not using a public/private key infrastructure. The private key is stored somewhere in the users .kde directory with read only to the owner. If the user authenticates via PAM kwallet is allowed to use the private key. The user can still close the wallet requiring to authenticate again (no matter how), if he wants to open the wallet.

Of course this does not really protect the wallet. But perhaps it would be possible that the user defines a passphrase, so he can choose if he wants to have comfort or security. Nevertheless the content would be encrypted in both cases.
Comment 48 Kai Bolte 2007-11-12 20:27:08 UTC
There is a discussion about fingerprint integration in KDM right here: http://bugs.kde.org/show_bug.cgi?id=116682 which has some similar points.
As mentioned there, now here to joerg / comment #46 : Everybody should decide for her/himself how secure her/his system should be - we probably can show a warning like "fingerprint login is insecure" :-). And it's "only" your two forefingers for the new passport and the same two fingers whichh they discuss for the ID - so you can use anotherone or a toe ;-).
So PAM would be perfect for KWallet - for me with pam_thinkfinger .
Comment 49 Mathieu Jobin 2007-11-13 00:33:25 UTC
if PAM is not the perfect backend for KWallet, why KWallet could not use multiple backends, the same way as Phonon uses multiple backends?
Comment 50 Tobias Schröpf 2008-11-16 12:11:52 UTC
I think the option proposed in comment #47 is just fine:
  * let PAM and the Core-OS do what they are designed for: Authenticate the user & authorize file access (here access to the secret key which is read-only for the authenticated user)
    [to me this behaviour would be similar to that of using SSH-Keys for passwordless SSH-authentication]
  * kwallet can use this secret key to encrypt/decrypt it's data

You could leave the option up to the user (in kwallets config) whether to use a secret key in the homedir or an "old-style" password.

From my point of view (which is the view of a user, not the one of a KDE/KWallet developer) the changes to kwallet would be small. No pam integration is needed, because when kwallet starts the user is already authenticated. The only thing that needs to be done is reading the secret key file (after assuring correct permissions (400)), and using the secret stored in this file instead of the password provided by the user

Comment 51 Michael Leupold 2008-11-16 12:36:28 UTC
It's not quite similar. In my opinion it's not useful to store an encrypted file and the key to decrypt it so close to each other. It seems like the security you gain by doing this is pretty close to not encrypting the file at all.
Comment 52 Michael Leupold 2009-02-16 19:41:34 UTC
*** Bug 184537 has been marked as a duplicate of this bug. ***
Comment 53 Markus Torstensson 2009-04-07 11:49:11 UTC
I have an additional idea, which I've posted in the KDE Brainstorming forum.
 
>Now when a program ask KWallet about credentials KWallet looks into it's >(proposed by me) database for this application. If the application is present, >KWallet checks if it's entitled to get the crential it's asking for, or else >KWallet asking me (graphicly) what I want to do: Give it access once, or >forever, not now, or not forever. If the application is not in the database >KWallet asks me if I would like to add it. (and then the other questions). >(Alternativly, only the application how put the credentials in KWallet can >fetch them from there)
 
>In this way I don't have to write passwords all the time. KWallet still asks >for permission, I'm in control. Bringing up the KWallet app-database lets me >modify my previous decisions to allow or disallow apps.
 
>This assumes two things which I really don't know anything about: 
> * KWallet have to have the means of making sure that an application really is >what it seems to be... it's really a developer thing, but since every antivirus >program in windows manage it (and the firewall to) I can't be that hard.
> * A program run as a user can't fiddle with another programs memory or windows >or such. IF this would be possible the asking (rouge) app could take control >over KWallet's dialog asking me for permession....

Is it out of scope?
Comment 54 Michael Leupold 2009-04-10 11:36:52 UTC
@Markus: This is actually already in. I mean not the pam stuff but the "ask if the application may access the wallet" thing.

There's a caveat though:
* kwalletd doesn't determine the application's identity but trusts the application on providing the name
Comment 55 Michael Leupold 2009-06-26 10:28:38 UTC
*** Bug 197788 has been marked as a duplicate of this bug. ***
Comment 56 Christoph Feck 2009-10-16 01:01:31 UTC
*** Bug 210726 has been marked as a duplicate of this bug. ***
Comment 57 Achim Herwig 2010-01-02 18:38:45 UTC
There is a PAM module and a client program available at http://download.opensuse.org/repositories/home:/hgraeber:/KDE4/

However, it tries to call DBUS method "tryOpen" that does not exists in any kwalletd that I examined (current KDE 4.3 packages for openSUSE 11.2 and KDE trunk), so it is not usable directly. It could be made to work with the "pamOpen" dbus method added by Michael (http://websvn.kde.org/?view=revision&revision=1054213), though.
Comment 58 Herbert Graeber 2010-01-08 23:26:21 UTC
(In reply to comment #57)
> There is a PAM module and a client program available at
> http://download.opensuse.org/repositories/home:/hgraeber:/KDE4/

This is only a version I tried to test an unfinished port of the KDE3 version of pam_kwallet.

> However, it tries to call DBUS method "tryOpen" that does not exists in any
> kwalletd that I examined (current KDE 4.3 packages for openSUSE 11.2 and KDE
> trunk)

tryOpen is an extension of kwalletd's dcop interface made by SUSE for KDE3. I had packages for kdebase4 with a similar extension the kwalletd's DBUS interface.

> so it is not usable directly. It could be made to work with the
> "pamOpen" dbus method added by Michael
> (http://websvn.kde.org/?view=revision&revision=1054213), though.

Now with this extension of kwalletd's DBUS interface pamOpen should be used. For this the program kwalletclient has to be changed to compute the has of the password before opening the wallet using pamOpen. The pam module pam_kwallet isn't needed because a pam module named pam_exec.so exists, which can do it's job.
Comment 59 Mathias Homann 2010-03-18 20:23:32 UTC
I would SO like to have a working pam/kwallet integration back.
maybe the one thing from kde3 that I'm missing most in kde4 right now.
Comment 60 Michael Leupold 2010-03-18 21:42:10 UTC
As there seems to be a lot of interest in getting this working, a little update from my side:
I'm currently working on this, but unfortunately it didn't turn out as easy as I hoped it would be. Currently the main problem is that PAM needs to launch the D-Bus session bus as well as kwalletd for automatically opening the wallet which turned out to be harder than expected.
Comment 61 alancio 2010-03-18 23:49:10 UTC
(In reply to comment #59)
> I would SO like to have a working pam/kwallet integration back.
> maybe the one thing from kde3 that I'm missing most in kde4 right now.

Mathias, what are you talking about? This never existed in kde3.
This wish has been open for 6 years, with thousands of votes, yet nothing has been done about it.  What we got instead in these 6 years is a "semantic desktop".
Comment 62 Javier Ortega Conde (Malkavian) 2010-03-19 17:19:16 UTC
(In reply to comment #60)

> I'm currently working on this, but unfortunately it didn't turn out as easy as
> I hoped it would be.

Thank you very much for your effort Michael. Hope you could get it done. Thanks
Comment 63 Wojciech Ryrych 2010-05-31 18:21:43 UTC
(In reply to comment #60)

Hi Michael!


It's almost 6 months since you wrote you were working on this so would be so kind to tell us how are you getting on? Will it be finished on next KDE release?


cheers,
Wojtek
Comment 64 Patrick 2010-06-24 16:14:16 UTC
Great idea! Any news?
Comment 65 Michael Leupold 2010-06-24 18:09:18 UTC
Unfortunately it won't ship with the next version of KDE. The main problem is that accessing KWallet at the same time you can access the password is quite hard. It requires a PAM module that can access the user's D-Bus session bus which is usually started after login only.

Now, the good thing is I worked around this by implementing a PAM module to launch the bus as well as the module that gets the password and sends it to KWallet and it's already working (well, at least for me). Unfortunately D-Bus developers seem to disagree that what I did was such a good idea. So until things have cleared a bit I won't do a real release of the modules. If you're able to you can however get the modules from here:
- http://code.confuego.org/index.php/p/pamdbuslaunch
- http://websvn.kde.org/trunk/playground/base/pam_kwallet
Comment 66 Javier Ortega Conde (Malkavian) 2010-06-24 19:17:10 UTC
Thank you very much for your work Michael! :) Hope to get a the solution integrated soon.
Comment 67 Michael Heide 2010-07-08 09:04:36 UTC
I think, not having kwallet opened with user login is a decrease in security in some cases. pam is running in a non-user-context while any login attempt in an already running user session runs in user context. As a result any password sniffing app must run in root context for the former one while for the second one user context is enough. (In case of attacking the "open kwallet"-process. Attacking kwallet directly is on par.)

Secondly. Having to type in a password twice in the login process is godawful, at least bothersome. Many people will prefer to use an empty password for kwallet because of this. This results in a _major_ loss in security. 

Even if there is some pam integration for kwallet, every one who wants can still use different passwords for os login and kwallet. So at least pam integration won't touch any security concerns for "the real safety-conscious people" out there. ;-)
Comment 68 Valery Yundin 2010-07-25 02:24:14 UTC
I wonder if it could be possible to make kwallet use ssh private key. There are already pam_ssh and ssh-agent in the most distributions. And this approach has no problems with D-Bus, because pam_ssh unlocks private key and ssh_agent keeps it until kwallet may want to access it.
Comment 69 Malte 2010-07-25 11:56:54 UTC
Vayu <yu.valery+bugzilla@gmail.com> wrote

> https://bugs.kde.org/show_bug.cgi?id=92845

> --- Comment #68 from Vayu <yu valery+bugzilla gmail com>  2010-07-25
>  02:24:14 --- I wonder if it could be possible to make kwallet use ssh
>  private key. There are already pam_ssh and ssh-agent in the most
>  distributions. 

An approach that sounds nice. But, does kwallet not still need to be made 
aware of PAM? I mean, if there is no PAM support at all in kwallet, nothing 
will work, no ssh_pam, not libpampoldi with openPGP card? Vice versa, once 
kwallet supports PAM, any PAM module would work with kwallet, right?

Regards
Malte
Comment 70 Ralf Weyer 2010-08-06 11:39:02 UTC
I'm not a developer, but one or two questions come to my mind when reading this bugreport:

The Gnome-devs seem to fixed this problem a long time ago. You can use the so called Gnome Keyring, and it will be opened directly when you login to the computer. So it seems they are using som kind of pam-module to open the keyring during login. So at last it is possible at all.

Wouldn't it be a good idea to talk to the Gnome devs and ask them how they did it, instead of reinventing the wheel again? Maybe it is possible to share some of the code, so it gets a little bit easier.

Or maybe it would be posssible to create a complete new wallet-like thing together with the Gnome-devs, so there would be only one wallet used in Gnome and KDE, just with different GUI for both desktop - one GTK+ and one QT (maybe a plasmoid?). And then create a pam-module together then can be used by either GDM and KDM to open the wallet, no matter which desktop is used.

Don't forget I'm not a developer. So it's a little bit hard to say for my if this is possible at all. At least it seems like a good idea. Maybe a disscussion at the next Akademy would be good, since it will take place together with GUADEC, so the perfect "get together" of KDE and Gnome developers.

Regards,

Ralf
Comment 71 Gary L. Greene, Jr. 2010-10-14 10:04:21 UTC
As someone that uses Kerberos and LDAP a lot, having PAM integration with KWallet would be a huge win, especially if we could get a plasma widget that did kinit and tgt renewal requests. :)
Comment 72 Robert Simmons 2011-01-22 20:50:36 UTC
This feature would be great.
Comment 73 Günter Haus 2011-03-03 11:05:31 UTC
It would be great to see any forthcoming on this. The current kwallet situation is absolutely terrible. Any of the above mentioned solutions would be a BIG improvement.
Comment 74 Beat Wolf 2011-03-03 11:10:21 UTC
indeed. Currently i'm forced to set a empty password for kwallet when i'm installing linux for somebody, simply because of usability reasons. A more secure solution would really be appreciated.
Comment 75 alancio 2011-03-03 11:50:03 UTC
This request has been here for 7 years already, it has thousands of votes, and yet it hasn't even been acknowledged by any developer, its status is still "NEW" after 7 YEARS!

Every new KDE release comes with more bugs, 4.6.0 in particular was terrible and I simply lost my motivation to report bugs and wishes that go ignored for years, this is just a waste of time.
Comment 76 John Layt 2011-03-03 13:33:50 UTC
alancio, I don't know how you can say it's been ignored, Michael Leupold has been working on this as documented above and it's really quite rude to say otherwise.  If Michael says it is harder than it looks, then it must be hard.  Remember, we are all volunteers here giving up our free time to work on KDE and we just can't do everything.

Something else to consider is that KDE and Gnome are currently working on a common standard for storing passwords called Secret Service which will be draining resources as well, and may well offer a common solution for the problem.

Personally I find KDE 4.6 to be the least buggy KDE ever (yes, even including KDE3, I think nostalgia makes people forget the bugs we had there).
Comment 77 Robert Simmons 2011-05-22 21:29:43 UTC
I have been hearing about a unified wallet between gnome and KDE, is this problem not being addressed because of a shift to a unified wallet?
Comment 78 Günter Haus 2011-07-19 12:00:18 UTC
It is really frustrating that such a badly needed feature hasn't even been started within 7 years, while dozens of completely useless features find their way to new KDE releases. 

Come on KDE team I'm shure you can do better and please at least update the status of this bug!
Comment 79 Todd 2011-07-20 13:52:38 UTC
What is "badly needed" and what is "completely useless" is a matter of personal opinion.
Comment 80 Markus Lohse 2011-07-20 14:16:06 UTC
Please stop asking questions like "Do you really need it? Absolutely sure???" This is only going to frustrate users.

I'm offering 25,- Euro to the guy/team who just gets it working, plus I can do some coding on the Qt/KDE (kwallet) part. Unfortunately, I don't know anything about PAM authentication and don't have the time to work myself in.

Looks like there is just nobody out there having enough knowledge about PAM, KDM and Kwallet at the same time. So I think this just needs some coordination and teamwork.

Of course as an alternative we can collect some money to write it out as a project for a freelancer.
Comment 81 Oswald Buddenhagen 2011-07-20 15:12:22 UTC
make that 2500€ and somebody *might* bite. just to give you an idea of what effort we are talking about.
Comment 82 Markus Lohse 2011-07-20 15:26:19 UTC
Well, 99 people (offering 25,-Euro) to go... and perhaps some student picks it up earlier :)
Comment 83 Javier Ortega Conde (Malkavian) 2011-07-20 15:45:05 UTC
I would pay 10€ more. ¿a good web to collect these award wills and try to make it real?
Comment 84 Giuseppe Calà 2011-07-20 15:47:24 UTC
If you're serious I donate 10 euros too!!
Comment 85 Mathias Homann 2011-07-20 15:54:54 UTC
will there be a written guarantee from the "KDE Management" or whatever else the organization that decides what goes in KDE $current+1 calls itself, to the effect that this feature doesn't get removed in the next version just after someone came up with the 2500€?
Comment 86 Achim Bohnet 2011-07-20 16:09:46 UTC
on planetkde a) lightDM was mentioned as a crossdesktop alternative to kdm.
and b) there was (freedesktop?) work goin on to unify
gnomes (that open wallet on login) and kde wallet system.

I hole heartly agree that it's very welcome to open the wallet at login time,
but one should check if kwallet+kdm  or lightDM+freedesktop-wallet or something else is the way implement the feature.

Achim
Comment 87 Ralph 2011-07-20 20:10:13 UTC
I'll give 10 Euros via Paypal if it gets fixed. The time saving would be enormous.

Ralph
Comment 88 Beat Wolf 2011-07-20 20:14:34 UTC
i'll chip in too
Comment 89 kde-bugtracker 2011-07-20 20:55:25 UTC
I will give 15 canadian dollars as well. It's been 7 years since this has been requested, enough is enough.
Comment 90 Stefan Feilmeier 2011-07-21 06:45:04 UTC
For a serious solution, expect my 25 € as well!

It's one of the bugs I hate the most in KDE.
Comment 91 Gary L. Greene, Jr. 2011-07-21 08:09:04 UTC
Please stop using Bugzilla as a pledging-for-work location for this wish-list item.

Unless the developer WANTS to code this up, understand this is THEIR prerogative, and criticising the devs by saying they "aren't doing anything" is both rude and unbecoming of a KDE community member. Remember, finding an itch and coding it is what F/OSS is all about, and KDE is driven as a meritocracy. In other words, if you want this, either hire someone to do it (and not through Bugzilla) or code it up yourself.

With that said, we get to the next gripe I have about all the posts on this item of late: this is neither the forum, or the mechanism for doing pledges-for-code. This tool is for triaging bugs and wish-lists for software. Please do me and all the others that are involved with this bug a favour and take it to another forum. Thanks.
Comment 92 Mathias Homann 2011-07-21 08:19:25 UTC
then maybe oswal should not have asked for people to pay to have this feature?
see comment #81.
Comment 93 at 2011-09-26 17:53:56 UTC
how tenacious can one be
Comment 94 Mathias Homann 2011-11-14 12:25:34 UTC
oh for effs sake. kdelibs4 *has* a pam_open dbus call into kwallet, but no pam module to call it???? wtf?
Comment 95 Mathias Homann 2011-11-14 13:49:15 UTC
can someone please close this as "worksforme".

there's a "pam_kwallet" in kde/playground/base and a pam_dbus_launch at http://code.confuego.org/index.php/p/pamdbuslaunch/

With those two modules, single sign on *works*.
Comment 96 Todd 2011-11-14 14:05:38 UTC
Until it is out of playground I wouldn't say it can be considered finished.  pam_kwallet doesn't appear to have had any commits in almost a year and a half.
Comment 97 Mathias Homann 2011-11-14 14:15:08 UTC
...so?

i've build the stuff just now and tried it, and it works fine.
and the dbus call that it uses has been in kwalletd since 4.4.2, so of course the accompanying pam module is *old*.
Comment 98 Michael Leupold 2011-11-14 14:17:41 UTC
This is known to work but due to various reasons it has never been
released. Number one of the reasons is that the D-Bus developers don't like the
way of starting the bus using a pam module and think it's plain wrong.
Comment 99 Todd 2011-11-14 14:21:46 UTC
If the developers don't think it should be used widely, which is what it means to be in playground, I think we should listen.
Comment 100 Malte S. Stretz 2011-11-14 14:28:05 UTC
Michael, is pam_kwallet your project, too?  I didn't even know it existed and like to have a look at it but it looks like both gitweb.k.o and anongit.k.o are down and the project isn't on projects.k.o.  Any chance to have this added to projects.k.o?
Comment 101 Mathias Homann 2011-11-14 14:32:51 UTC
Maybe the dbus developers should think about providing a way to start the dbus service that is not "plain wrong"?

all I can say is, in this day & age a single-sign-on method for kwallet is a must have.

The one with the pam modules works.
good enuff for me.
Comment 102 Michael Leupold 2011-11-14 14:35:26 UTC
@Malte: yeah, I developed both modules to fix this bug quite a while ago. I haven't worked on it since its last commit. Not sure if it's actually worth it - when the time is ready it should probably be adapted to work with the new secret service.
Comment 103 Malte S. Stretz 2011-11-14 15:04:01 UTC
Support for Secret Service is pending for two or so years now.  That's not meant as a criticism of your  work, I'd just like to have something which just works now and until the real thing arrives.  I have an idea on how to circumvent the dependency on pam-launch-dbus and might hack pam-kwallet to make it work in a spare minute.

Ah, gitweb is back.  I can see some work happening in ksecretservice.git but can't find a pam[-_]kwallet.git (anongit is still down).
Comment 104 Mathias Homann 2011-11-14 15:14:30 UTC
what is this "ksecretservice" you guys are talking about?

and like Malte already said... pam_kwallet works *now*, not *at some point in the distant future*.
Comment 105 Malte S. Stretz 2011-11-14 15:35:09 UTC
Secret Service is a joint specification by KDE's KWallet and Gnome's Keychain to have a unified API for unlocking the secrets on logon and accessing them later on.  You can look it up here: http://standards.freedesktop.org/secret-service/
Comment 106 Mathias Homann 2011-11-14 15:42:10 UTC
looks quite intriguing..
...but...

are there actual working implementations yet?
Comment 107 Todd 2011-11-14 15:47:07 UTC
Yes, ksecretservice is being released as we speak.  They are just trying to decide where to put it in the git tree.
Comment 108 Mathias Homann 2011-11-14 15:49:24 UTC
so what do i do with it as of now?

replace kwallet with it?
Comment 109 Todd 2011-11-14 15:53:20 UTC
Nothing, there will be more information once it is decided how it is going to be handled.  At best it will not be available until 4.8, at worst not until frameworks.
Comment 110 Mathias Homann 2011-11-14 15:59:43 UTC
that's what I expected.
Comment 111 Mathias Homann 2011-11-14 17:29:05 UTC
grmbl. seems that pam_kwallet does not want to work in a NIS setup :(
Comment 112 Leon Maurer 2011-11-28 03:29:02 UTC
Is there an easy way for regular users such as myself can get this thing in playground working? The continuing lack of single sign on is absurd.
Comment 113 Nick Cross 2012-01-13 21:33:40 UTC
Having found this ticket (and the lack of action on it!) I wrote myself a small script for the kde/Autostart folder that simply talks to kwallet and calls kerberos kinit (with appropriate kdialog prompting if needed). Seems to work ok for me as a workaround.
Comment 114 Markus Lohse 2012-01-14 01:10:56 UTC
Finally, there's light at the end of the tunnel :)
I've just found this in the kde-4.8 RC2 release notes:
"KSecretService optionally enables a shared password storage, therefore making your saved passwords available to many other applicatios, leading to a more secure system and better integration of non-KDE apps into the Plasma Workspaces and KDE apps into non-Plasma workspaces." (see here: http://www.kde.org/announcements/announce-4.8-rc2.php )
Comment 115 Nick Cross 2012-01-14 07:26:46 UTC
kSecretService was mentioned already in this thread and information is available here
http://techbase.kde.org/Projects/Utils/ksecretsservice
http://standards.freedesktop.org/secret-service/
http://dot.kde.org/2011/12/22/kde-makes-first-48-release-candidate-available-adds-secret-service

However as its still early on in development I did not want to wait hence writing something that just works now so I have ssh/kerberos keys/passwords all working from kwallet on login.
Comment 116 Henning 2012-01-14 18:20:31 UTC
Hi nick,

Can you please provide your workaround script here ?
I still won't wait until the ksecretservice is ready for use.
Thanks


(In reply to comment #113)
> Having found this ticket (and the lack of action on it!) I wrote myself a small
> script for the kde/Autostart folder that simply talks to kwallet and calls
> kerberos kinit (with appropriate kdialog prompting if needed). Seems to work ok
> for me as a workaround.
Comment 117 Nick Cross 2012-01-15 15:44:19 UTC
Hi,

Sure. I will finish up another of my use-cases (I want it to automatically get a kerberos key after a VPN has been activated) and then write it all up.
 
(In reply to comment #116)
> Hi nick,
> 
> Can you please provide your workaround script here ?
> I still won't wait until the ksecretservice is ready for use.
> Thanks
> 
> 
> (In reply to comment #113)
> > Having found this ticket (and the lack of action on it!) I wrote myself a small
> > script for the kde/Autostart folder that simply talks to kwallet and calls
> > kerberos kinit (with appropriate kdialog prompting if needed). Seems to work ok
> > for me as a workaround.
Comment 118 Nick Cross 2012-01-15 20:26:21 UTC
My scripts are here: https://github.com/rnc/kde-scripts

Hope they help - works for me ;-)
Comment 119 Luiz Angelo De Luca 2012-01-15 21:26:54 UTC
Hello Nick,

I took a look at your scripts. They use a password stored in kwallet to initialize kerberos tgt (kinit). Isn't it?

This bug is about the "oposite": open kwallet using the login/pam password. Maybe others got confused as I did. The idea is that pam could provide the passoword in order to open kwallet (or ksecretservices) without asking the user again for a password, just after it has already provided one for its login process.

BTW, if you want to always use kerberos, why not just use pam_krb5.so? You will authenticate using the kerberos password and will get the TGT "for free". If you use kerberos from AD, pam_winbind.so also provides the TGT (just like kinit) and allow other nice features like offline authentication.
Comment 120 Nick Cross 2012-01-16 08:36:43 UTC
(In reply to comment #119)
> I took a look at your scripts. They use a password stored in kwallet to
> initialize kerberos tgt (kinit). Isn't it?

Yes true.
 
> This bug is about the "oposite": open kwallet using the login/pam password.
> Maybe others got confused as I did. The idea is that pam could provide the
> passoword in order to open kwallet (or ksecretservices) without asking the user
> again for a password, just after it has already provided one for its login
> process.
> 
> BTW, if you want to always use kerberos, why not just use pam_krb5.so? You will
> authenticate using the kerberos password and will get the TGT "for free". If
> you use kerberos from AD, pam_winbind.so also provides the TGT (just like
> kinit) and allow other nice features like offline authentication.

Ah ok sorry :-) Well not wasted as its useful for me ;-) Thanks for the hint; might look at it.
Comment 121 Mathias Homann 2012-03-09 08:11:16 UTC
what happened to KSecretService?

I'm running KDE 4.8.1 on openSUSE 12.1 and there are no packages available.
Comment 122 Mathias Homann 2012-03-09 08:18:28 UTC
besides, I don't think that changing from the old system to ksecretservice would even cover the topic of this request at all...


this request is about how people do not want to enter their password twice in a row.

once to log in on their computer, the second time when kopete or chokoq gets autostarted.
Comment 123 Christoph Feck 2012-09-25 19:38:45 UTC
*** Bug 307396 has been marked as a duplicate of this bug. ***
Comment 124 Mathias Homann 2012-12-23 16:06:33 UTC
so... we're at KDE 4.9.4 by now; KDE 4.10 is in feature freeze... Will there be a reliable single-sign-on in it?
Comment 125 Beat Wolf 2012-12-23 23:02:55 UTC
setup your kwallet to use an empty password, that way you dont have to type the password during the login. Yes, its not secure, but its way less annoying
Comment 126 Mathias Homann 2012-12-23 23:08:11 UTC
I hope you're joking...
Comment 127 Beat Wolf 2012-12-23 23:13:28 UTC
I'm actually serious. I'm no dev and i doubt anybody works on this. So my only practical solution i found is to set an empty password. It was either that or not using kwallet at all. Kwallet is useful so i opted for the password less version (and do so for all computers i install with KDE, the double login is not acceptable for the average user)
Comment 128 kde-bugtracker 2012-12-23 23:27:35 UTC
The way I work around this in a relatively secure way is to use full-disk encryption (LUKS). Then you can set KWallet without a password, and you can even set KDM to log you in automatically without a password (with the screensaver lock enabled at startup perhaps). This way, the only password you'd need to enter is the one used to decrypt your entire partition.

This is obviously vulnerable to malicious applications running on your system once it is booted and you've entered the decryption password. But then again, even KWallet is vulnerable to malicious applications running on your system once you're logged in anyway, because all an application needs to do is to request KWallet access, and then simulate a click on your behalf on the "Always allow" button.

However, at least this setup is secure against attacks while your computer is off (someone steals your laptop or something).
Comment 129 Martin Flöser 2012-12-24 07:07:49 UTC
as a matter of fact KWallet is not very secure in the first place. With a 
password it is secure as long as you have not opened the wallet. Once the 
wallet is open it is unsecure in the following (obvious) ways:
* all information on how to read the passwords has to be in memory. Reading 
the memory would provide the passwords. Turning of the system would not 
protect against it (cold boot attack [1])
* there is no authentication between applications and the wallet. Establishing 
authentication is hardly possible on an open system.

Overall I would say if you do not fear that someone would get access to your 
turned off system there is no need to have a password. That is a desktop 
system is probably fine without a password, but on a notebook which could be 
stolen one should consider using one. There is probably a higher risk from 
malware interacting with the open wallet than that someone steals the hard 
disk.

In most cases the mentioned LUKS solution is excelent, though I just need to 
point out that it's of course also breakable by cold boot attacks.

I'm not a KWallet developer, just subscribed to this report and interested in 
IT security (was my major in my Masters program). If you know think that 
KWallet is insecure: be aware that these are problems probably visible in all 
password store solutions. The security model of Linux is "if it runs, it's 
trusted", which means one does not have to consider malicious software.

[1] http://en.wikipedia.org/wiki/Cold_boot_attack
Comment 130 Alexander Mezin 2013-03-24 16:16:18 UTC
Were there any attempts to implement it since pam_kwallet?

Of course, starting session bus from pam module isn't a good idea.
But what's the problem with this approach:
1. From pam module, start a process and pass password to it
2. The process waits for "ready" signal from kwallet (signal can be passed, for example, using sockets)
3. At some time kwalletd starts, sends signal to the process
4. The process sends password to kwallet (using d-bus call)
Comment 131 Dennis Schridde 2013-03-24 17:02:25 UTC
(In reply to comment #130)
> But what's the problem with this approach:
Sounds good. I also had an idea that is (in theory) even simpler: Just start KWallet from PAM and pass it the password (e.g. via stdin).
Comment 132 Alexander Mezin 2013-03-24 17:20:24 UTC
This is almost how it's done in gnome-keyring. Take a look on it's code and especially on comments about pam.
I'm not sure that kwalletd started from pam module will be able to work.
Comment 133 jpxsat 2013-03-25 02:27:07 UTC
I have a little enterprise and we use Linux (Ubuntu to be exact) since 2010.
I've recently tried Kubuntu and felt in love with it, so I began to try everything in my new KDE system... and what I get just after an automatic login? the system is requesting for my password??
I mean, come on... there's no way KDE is the only desktop out there without a full automatic login? even windows does that...
Excluding this, KDE is absolutly marvelous.
Devs: IMHO if you want to catch all the possibles users, you have to let them use their system as they want... and lots of normal users just does not want to EVER put a password at any time on their computers. So PLEASE... make this happen :)
Comment 134 Luiz Angelo De Luca 2013-03-25 02:46:40 UTC
@jpxsat,

I'm no expert in pam/kwallet but this bug is not related to your request.

The password in kwallet is used to protect the sensitive data that are stored inside the wallet.
The request in this bug is: "if I used the same password for kwallet and the user login, why not copy this password from the login and use it to try to open kwallet?"

The autologin does not store your password and use it to login normally. It just "su" to your user and runs KDE. So, If you use autologin, the system does not know your the password. If kwallet is protected, it need its password in order to read its data.

If security does not concern you, you need to use kwallet without a password. However, be warned that anyone with access to your filesystem would easily read all your passwords stored in kwallet.
Comment 135 jpxsat 2013-03-25 13:04:32 UTC
@Luiz Angelo De Luca

Thanks to your comment I tried (never wanted to, but now I did) turning off KWallet. It seems that it solves my problem.

I still think that my issue was somehow related to this bug, because if I wanted for KWallet to open automaticly with autologin should not this be the "bug" to fix?

Thanks for giving me the idea for turning off KWallet :)
Comment 136 Christoph Feck 2013-04-30 01:18:24 UTC
*** Bug 291933 has been marked as a duplicate of this bug. ***
Comment 137 Murz 2013-07-22 11:10:22 UTC
Ubuntu Linux have feature for user home folder encryption, it works with password that user enter on login, this is done via pam_ecryptfs.so module. So nobody can decrypt data without knowing user password. Maybe kwallet can reuse this method for opening kwallet via user password?
Comment 138 Mathias Homann 2013-08-13 10:22:20 UTC
... kde 4.10.5 by now, KDE 4.11 is in RC2, any signs of process on this one?
Comment 139 Mathias Homann 2013-10-25 21:00:27 UTC
KDE 4.11.2 by now, any progress on this?
The pam modules don't work with NIS users...
Comment 140 Mathias Homann 2013-10-26 20:35:59 UTC
I managed to get pam_kwallet to work with NIS, for details, see here:
http://linux.eregion.de/2013/10/26/kwallet-single-sign-on-at-last/
Comment 141 Mathias Homann 2013-10-26 20:49:57 UTC
I suggest pam_dbus_launch and pam_kwallet make it into KDE 4.12 or KDE 5.0.
Comment 142 gemlion 2013-10-28 21:36:13 UTC
This is one of the most wanted features in KDE since 2005 - and the only one that really annoys me about KDE, which otherwise is an outstanding DE. Hope it gets implemented soon :)
Comment 143 Murz 2013-11-04 19:20:49 UTC
http://linux.eregion.de/2013/10/26/kwallet-single-sign-on-at-last/ provide very good solution, that solves this issue, tested and works for many people. But now it available only for OpenSUSE, other Linux system don't have easy-to-install ways. Can you import this modules to future KDE SC releases?
Comment 144 Mathias Homann 2013-12-11 07:38:22 UTC
I would like to point out that gnome 2.x on Red Hat Enterprise Linux 6.x has been doing exactly this for the gnome password storage for ages.

So ... if the likes of red hat and gnoe can do this, should the KDE team really waste 8 years in a moralistic discussion about its emotional merit and security value?

If security worries you, make it so that the feature is OFF by default, and the user gets a warning first time they enable it.
Comment 145 kdeuser56 2014-02-16 09:47:48 UTC
Is there anything planned for frameworks 5 in that regard? I would agree to make an option for this (and try to make it as secure as possible), but disabling it by default in case of security concerns.
Comment 146 Achim Bohnet 2014-02-16 10:30:08 UTC
(In reply to comment #145)
Seems so:  https://plus.google.com/+%C3%80lexFiestas/posts/CarwXy8v85b
Comment 147 Divan Santana 2014-04-21 07:17:42 UTC
For those that haven't yet noticed, looks like Kubuntu 14.04 LTS has this working:

"PAM KWallet git20140410

New single sign-on capabilities for the password manager KWallet. Allowing new wallets to be automatically be created on first login and automatically unlocked on subsequent logins. "

Hopefully other distro's and upstream will pick this up soon.

https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes/Kubuntu#PAM_KWallet_git20140410
Comment 148 Murz 2014-04-21 07:59:38 UTC
Thanks, very cool! But I can't find any howto or manual how to use and configure it. 
Divan Santana, can you post short description how I can I enable auto unlocking KDE Wallet on login for old wallet on Kubuntu 14.04? Thanks.
Comment 149 Mathieu Jobin 2014-04-25 01:32:23 UTC
wow
Comment 150 Luca Beltrame 2014-04-25 10:20:24 UTC
Some general instructions can be found here (I wrote the post):

https://www.dennogumi.org/2014/04/unlocking-kwallet-with-pam/
Comment 151 Jesse Litton 2014-04-25 11:58:03 UTC
unsubscribe
Comment 152 Mathias Homann 2014-04-25 15:01:54 UTC
@Luca, I have tried to build and install that module according to the instructions in your blog post... doesn't work. And no error messages either. Is there a way to switch it to verbose or such?
Comment 153 Mathias Homann 2014-04-25 15:03:06 UTC
@Luca, I have tried to build and install that module according to the instructions in your blog post... doesn't work. And no error messages either. Is there a way to switch it to verbose or such?
Comment 154 imraro 2014-04-25 15:06:25 UTC
Arch x86_64: pam_kwallet(systemd-user:session): pam_kwallet: open_session called without kwallet_key
Comment 155 Luca Beltrame 2014-04-25 15:36:55 UTC
I am not sure how to debug this, as I figured the steps with trial and error. Can you try installing socat?
Comment 156 imraro 2014-04-25 15:42:10 UTC
I'm not familiar with socat. Could you explain, how to use it in this case?
Comment 157 Luca Beltrame 2014-04-25 15:48:15 UTC
The Ubuntu package lists it as dependency. I forgot if I had it installed at the time of my tests.
Comment 158 imraro 2014-04-25 15:53:16 UTC
What do you mean by "Ubuntu package lists"?
Comment 159 Josiah Ritchie 2014-04-25 15:55:21 UTC
unsubscribe



On Fri, Apr 25, 2014 at 11:53 AM, imraro <imraro@gmail.com> wrote:

> https://bugs.kde.org/show_bug.cgi?id=92845
>
> --- Comment #158 from imraro <imraro@gmail.com> ---
> What do you mean by "Ubuntu package lists"?
>
> --
> You are receiving this mail because:
> You voted for the bug.
>
Comment 160 Luca Beltrame 2014-04-25 15:58:35 UTC
The pam-kwallet package in Ubuntu has socat as dependency. Whether this helps or not I do not know as there is no documentation and this stuff is low level.
Comment 161 imraro 2014-04-25 16:05:07 UTC
Nothing has changed after installing socat.
Comment 162 Orion Poplawski 2014-04-25 16:39:55 UTC
(In reply to comment #151)
> unsubscribe

Remove yourself from the CC list.
Comment 163 Orion Poplawski 2014-04-25 16:40:51 UTC
(In reply to comment #159)
> unsubscribe
> > You are receiving this mail because:
> > You voted for the bug.

actually, remove your vote from the bug
Comment 164 Luca Beltrame 2014-04-25 16:52:03 UTC
Apparently to get this to work you need 3 commits that did not make into 4.13 
and will likely be in 4.13.1.

More seriously, I would suggest people that need this to use Kubuntu, that 
somehow got this to work. I can't even reproduce my work on another machine, 
so I'm guessing that either the author or someone with deeper PAM knowledge 
steps in, or it's just a waste of time.
Comment 165 Luca Beltrame 2014-04-25 17:05:41 UTC
FWIW, I updated the blog entry with more possible suggestions. But at least 
for me I can't get it to work with KDM.
Comment 166 imraro 2014-04-25 18:16:29 UTC
I'm using lightdm and git-repos for pam_kwallet )
Comment 167 imraro 2014-04-25 18:23:47 UTC
(In reply to comment #163)
> (In reply to comment #159)
> > unsubscribe
> > > You are receiving this mail because:
> > > You voted for the bug.
> 
> actually, remove your vote from the bug

Removing of a subscription and removing of a vote is not same, isn't it?
Comment 168 Herbert Graeber 2014-04-25 19:43:37 UTC
(In reply to comment #160)
> The pam-kwallet package in Ubuntu has socat as dependency. Whether this
> helps or not I do not know as there is no documentation and this stuff is
> low level.

the socat is not strictly needed by pam_kwallet itself, but by the startkde script. But only when pam_kwallet is installed, too.

(In reply to comment #161)
> Nothing has changed after installing socat.

The following lines are needed in /usr/bin/startkde and are missing in openSUSE (ubuntu and fedora already have them):

if test -n "$PAM_KWALLET_LOGIN" ; then
  env | socat STDIN UNIX-CONNECT:$PAM_KWALLET_LOGIN
fi
Comment 169 Luca Beltrame 2014-04-25 19:47:08 UTC
Yes, my bad on that. I forget I run git master on my main box, which has already these commits in (but 4.13 hasn't them).
Comment 170 Herbert Graeber 2014-04-25 19:58:00 UTC
Created attachment 86268 [details]
Adds pam_kwallet support to startkde
Comment 171 Mathias Homann 2014-04-26 06:39:19 UTC
I've set this up and it works, but only for local users. Does not work for network user accounts (i.e. NIS). Don't have a LDAP server here to test that.
Comment 172 Luca Beltrame 2014-04-26 06:48:58 UTC
On which distro did you set this up? Any changes from what I wrote? So that I can amend the guide as necessary.
Comment 173 Mathias Homann 2014-04-26 07:20:46 UTC
I'm using openSUSE 12.3 here, no changes from your blog post. when I login using a locally set up account, it works; logging in with a user account from NIS it doesn't.
Comment 174 Mathias Homann 2014-04-26 07:59:01 UTC
ok now i'm at the "huh?" stage of this; two identical machines, and I literally copied the config and libraries from one to the other, and on one computer it works for both local accounts and NIS, and on the other it doesn't work for any of them.
Comment 175 Luca Beltrame 2014-04-26 08:04:52 UTC
In data sabato 26 aprile 2014 07:59:01, hai scritto:

> computer it works for both local accounts and NIS, and on the other it
> doesn't work for any of them.

I've had the same issue when trying to generalize the guide. I guess we need a 
PAM expert to debug this...
Comment 176 Lukas Jirkovsky 2014-04-26 08:40:39 UTC
Oh come on guys, bugzilla is not a forum.
Comment 177 Luca Beltrame 2014-04-26 09:08:29 UTC
In data sabato 26 aprile 2014 08:40:39, hai scritto:

> Oh come on guys, bugzilla is not a forum.

Indeed, we have the KDE Community Forums.  I've taken the liberty of creating 
a post discussing the configuration, to keep this entry cleaner (although 
anyone could have posted that, instead of just saying "bugzila is not a 
forum"):

http://forum.kde.org/viewtopic.php?f=14&t=120843

Please direct further discussion on how to hook KWallet with PAM there.
Comment 178 Leon Maurer 2015-05-01 14:47:36 UTC
Single sign-on no longer works for me when I upgraded to Kubuntu 15.04 and plasma 5.3. Does anyone know if this is because of a problem with Kubuntu or because the feature hasn't made it to KDE 5? (Or maybe the feature is still there but I need to enable it somehow?)
Comment 179 Orion Poplawski 2015-05-12 14:43:35 UTC
Looks like pam-kwallet needs to transition to kwallet5.  But this needs to be tracked elsewhere.
Comment 180 Leon Maurer 2015-06-10 21:16:30 UTC
As Orion suggested, I filed a new bug to request that this feature is revived in KDE 5. See Bug 349003.

(Am I the only person who misses this feature? This thread is awfully quiet considering the number of votes it got...)
Comment 181 Ettore Atalan 2015-06-11 16:46:44 UTC
(In reply to Leon Maurer from comment #180)
> As Orion suggested, I filed a new bug to request that this feature is
> revived in KDE 5. See Bug 349003.
Thanks.


> (Am I the only person who misses this feature? This thread is awfully quiet
> considering the number of votes it got...)
No, but most have given up on requesting this common feature.
Comment 182 Murz 2015-06-15 05:59:57 UTC
> (Am I the only person who misses this feature? This thread is awfully quiet considering the number of votes it got...)
I very want to vote, but didn't see Vote function in Bug #349003 but in this bug I can vote. Maybe you post the bug with wrong type?
Comment 183 Andrey 2015-07-18 15:41:04 UTC
I just use KWallet without password because I don't want to wait single-sing-on next year or two and I don't want to type my password again.
Comment 184 Ettore Atalan 2015-07-21 22:05:21 UTC
This request is from 2004. Expecting this feature in one or two years is quite optimistic.
Comment 185 Leon Maurer 2015-07-21 22:08:34 UTC
This thread is dead. Checkout the new bugreport for KDE 5 (Bug 349003). It looks like the feature may be added back soon; there's already a patch.
Comment 186 Bernie Innocenti 2015-07-22 01:47:11 UTC
(In reply to Leon Maurer from comment #185)
> This thread is dead. Checkout the new bugreport for KDE 5 (Bug 349003). It
> looks like the feature may be added back soon; there's already a patch.

Great news, but then why is this bug still open?
Can we just close it as WONTFIX / OBSOLETE?
Comment 187 Leon Maurer 2015-07-22 02:07:27 UTC
That seems reasonable to me. We should probably put this thread out of its 10+ year misery.