Opened 9 years ago

Closed 3 years ago

#673 closed enhancement (fixed)

Keyring support for password storage

Reported by: shirish Owned by: rlaager
Milestone: 3.0.0 Component: privacy
Version: 2.0 Keywords:
Cc: IceWil, Dawudd, elreydetodo

Description (last modified by rlaager)

Various keyrings should be supportable:

  • gnome-keyring
  • OS X's Keyring

Attachments (1)

pidgin-keyring-support.patch (24.3 KB) - added by grddev 5 years ago.
Patch implementing support for keyring plugins without changing existing APIs

Download all attachments as: .zip

Change History (44)

comment:1 Changed 9 years ago by datallah

  • Type changed from defect to enhancement

This should be a more generic request.

This enhancement should be abstract enough that implemenations for GnomeKeyring? KDEKeyring and the Windows equivalent could be made.

comment:2 Changed 9 years ago by rekkanoryo

I can see Evan and the Adium gang wanting this abstracted for putting in the Mac OS X keyring-like stuff too.

comment:3 Changed 9 years ago by rlaager

  • Description modified (diff)
  • Summary changed from Something like gnome-keyring for pidgin-win32 to Keyring support for password storage

comment:4 Changed 9 years ago by lewiz

I'd like to add a 'me too' to this. Specifically there are fundamental flaws with the PlainTextPasswords page:

In many corporate situations a single username/password is used for all access, e.g. email, session, IM, etc. Under these circumstances it becomes important to protect that single password.

comment:5 Changed 9 years ago by acornejo

I believe it is very naive to set this bug with a "minor" priority. In a lot of places (for example large corporations or universities) all your home directory is exported using AFS/NFS or similar.

In any case, what this means is that any system admin can view your home directory at will, since pidgin stores all its passwords in plain text, now it also means that the system admins can read my (and every other pidgin user) email without the users consent.

Please strongly reconsider upgrading this bug to critical. Even on single user systems, anyone can insert a boot disk/cd to gain access to your home directory without your password. Usually that means they can access all your files, but at least they cannot retrieve your password. However if the user happens to be a pidgin user, the intruder can gain all your passwords (and usually at least one of your email accounts password matches your desktop password).

Anyway, just my 5 cents.

comment:6 Changed 9 years ago by rekkanoryo

The priority here is meaningless. To us as developers, this is not something that is critical to the next release, as the existing method works just fine for us. We have long stated the fact that if you can't trust the people with access to your machine, you should not be storing passwords on it at all.

comment:7 Changed 9 years ago by lewiz

This is critical to many people in a corporate environment. I would go as far as saying it is a show-stopper (i.e. a single-sign-on LDAP password).

Sun already ship a version of Pidgin with gnome-keyring integration in recent Nevada builds to address these issues.

Is there any developer that can suggest what the appropriate architectural way of implementing this support would be done? I am very willing to spend the time working on a proper solution to this problem if I can get an idea of exactly how best to tackle it.

I understand we do not want to *require* linking against gnome-keyring, OS X's mechanism, etc. so some form of extended plugin must be required. Can anybody provide more details for me to look into?

comment:8 Changed 9 years ago by rekkanoryo

Any implementation that wants to get accepted into libpurple proper will be abstracted--that is, make a generic API for it that generically wraps the functionality provided by gnome-keyring, KDE's wallet, OS X's keychain, whatever mechanism is available on Windows, etc.

This would be similar to how our SSL plugins are set up, where a uniform interface is provided and the plugin itself deals with the differences between the purple API and the library's API.

comment:9 Changed 9 years ago by acornejo

Is there any way that we could use some kind of hack (temporarly), something on the lines of:

#ifdef LINUX_GNOME_BUILD

use gnome-keyring

#else

store as plain text

#endif

And add the proper configure flags to enable/disable it?

And by the way, IMHO it's strange that just because you (the developers) are not working on a corporate environment, or on a university with AFS/NFS you consider this just a "minor" feature/enhancement request, I'm sure a lot of users would appreciate such an "enhancement", since not even browsers store their passwords on plain text.

Anyway, if you guys are willing to take such a patch, maybe more people will be willing to do the work (I could probably do it). Then when one of the developers has the time or need to have secure passwords you can implement the abstraction and we can modify the patch to work on such an abstraction. But if people have to jump through hoops to get their patch accepted, its a long shot this will ever get fixed. I for one, could take the time to design the abstraction, but since I don't have access/experience with windows/osx/kde it's pretty unlightly that my abstraction will work properly with other keyring managers.

Again, just my opinion, I know you guys (developers) probably also have regular jobs and have bigger fish to fry on the bug list.

comment:10 Changed 9 years ago by rlaager

Now now, I love my single-sign-on at work that I've implemented via gnome-keyring. I really wish that Pidgin and Epiphany used it. For Pidgin, though, I haven't had the chance to deal with that yet.

The API here isn't going to be very complicated. Basically, you need to be able to get and set a password for a given account. The API should be non-blocking, which means that the core would do something like this:

purple_get_password(account, my_callback);

This function would pass control to the hook registered by the authentication plugin, which would query the keyring and then call the callback with the results. If there was no hook function, the existing XML storage would be used.

The plugins should be set to auto-load, just like SSL plugins do. Similar to logging, each plugin would register a named method. Then the UI would present a preference where the user could choose an appropriate method. The default could be managed like this pseudo-code:

if (purple_running_gnome() && auth_plugin_exists("gnome-keyring")

Use the gnome-keyring

else

Use the internal method

Then, someone could implement a plugin for KDE or OS X or whatever and we could add those.

Changing the preference from one back-end to another could prompt a box asking if it should copy all the passwords from the old back-end to the new back-end. Alternatively, it could just do the copy. We may want to prompt before overwriting a password in the new back-end. This would allow people to switch over to the internal back-end if they wanted to be compatible with other systems, for example.

comment:11 Changed 8 years ago by rlaager

  • Owner set to rlaager
  • Status changed from new to assigned

comment:12 Changed 7 years ago by zanko

A solution may be to use PPassKeeper which is a library that offers an abstraction layer with a plugins system for gnome-keyring, kwallet, soon for mac os X keyring and for plain text files where there is no other solution.

comment:13 Changed 7 years ago by mupuf

Hi, I'm the creator of PPassKeeper. I totally agree with zanko, PPassKeeper is made to solve your problem.

At the moment, the project is still in development. We need to find the best API and then freeze it before reaching 1.0. The beta 2 should be released soon. We are still doing minor improvements to the API. The project becomes really mature and already works on mac OS X, Windows XP/Seven, Linux/KDE and Linux/Gnome?.

The major point of using PPassKeeper is that you give users the opportunity to save their passwords wherever they want. For instance, it can be stored on a server using ftp, ssh, webdav or locally on the Windows's vault, mac os's keychain, KWallet, GnomeKeyring?. Users just need to find the suitable plugin and install it.

I am ready to discuss with anyone about both the API and the integration. I am also ready to maintain this code in pidgin.

comment:14 Changed 7 years ago by darkrain42

  • Component changed from pidgin (gtk) to libpurple
  • Milestone set to 3.0.0

There was a SoC project in 2008 to add support for master password backends (integrating with, I believe, initially Gnome Keyring and possibly KWallet(?)). See http://developer.pidgin.im/viewmtn/branch/shortchanges/im.pidgin.soc.2008.masterpassword for details.

The code hasn't been integrated yet because there are a few remaining details and, I think, we're aiming for 3.0.0 (presumably to just drop purple_account_get_password).

comment:15 Changed 7 years ago by mupuf

OK, I'll have a look at it as soon as possible.

Thanks

comment:16 Changed 6 years ago by darkrain42

Ticket #11314 has been marked as a duplicate of this ticket.

comment:17 follow-up: Changed 6 years ago by pva

We've received request in Gentoo for this issue: http://bugs.gentoo.org/show_bug.cgi?id=307169

There are reports that patch from opensuse works fine (see attached patch in our bug). This means that some distributions already include such support, but what about upstream? Are there any chances for this to happen in near future?

comment:18 in reply to: ↑ 17 Changed 6 years ago by rekkanoryo

Replying to pva:

There are reports that patch from opensuse works fine (see attached patch in our bug). This means that some distributions already include such support, but what about upstream? Are there any chances for this to happen in near future?

The patch from openSUSE actually does have a few particularly annoying bugs, such as losing saved passwords. We already have some keyring support in a branch developed by one of our Summer of Code students, and while we could integrate it prior to 3.0.0, it's going to be better for everyone, distributions included, if we wait for 3.0.0 to do so. That said, currently, I'm aiming for 2.7.x to be the last of the 2.x.y series, providing bug and security fixes while we work on integrating a lot of our previous Summer of Code work and removing deprecated API for 3.0.0. If all goes according to my plan and desires, we could have a 3.0.0 by year end (but don't even think about holding me to that--my plans often fail around here!).

comment:19 Changed 6 years ago by mupuf

Well, I'm OK with waiting for pidgin 3.0 to get some keyring support, but please, make the storing API available for plugins (or, you could also link directly to ppasskeeper which will abstract the password storing system for you).

Indeed, you won't support any possible way of storing passwords. Delegating the dirty work to plugins or ppk would really help to get multi-platform support.

comment:20 Changed 6 years ago by samee

Ok, I get the arguments here, so how about implementing it as a plugin instead of doing it in libpurple? That way, no compatibility issue comes up. I'm no plugin expert, so please comment on if this is doable (esp. without purple modification). If so, I can help implementing it:

  • As far as libpurple is concerned, no passwords are being remembered
  • In reality, they are being stored in a place accessible by a plugin (let's call it "TheMaster"), likely encrypted by a master password
  • TheMaster loads up when pidgin loads, which asks for a master password, decrypts the keys, and sets the account passwords at runtime just before they start connecting.
  • libpurple finds the passwords in the PurpleAccount already set, so avoids asking the user for any, and simply goes on to use TheMaster-supplied passwords (this is the part of purple behavior I'm unsure of)

If this is possible, it could be a great solution to a sore issue, with little or no change in libpurple. Any comments on feasibility and locations of changes required would be appreciated.

comment:22 Changed 6 years ago by nodiscc

Hello all,

did you see this? http://code.google.com/p/pidgin-gnome-keyring/ found it after a little searching, but i'm not sure if I can trust the code (have no C skills)... Could someone check and let us know?

Thanks

comment:23 Changed 5 years ago by landroni

Would the devels consider including pidgin-gnome-keyring in the official list of plug-ins? The 200lines of code are licensed under GNU GPL v3.

comment:24 Changed 5 years ago by BuZZ-dEE

I don't think that is a good idea for now, because of that: http://code.google.com/p/pidgin-gnome-keyring/issues/detail?id=2.

comment:25 follow-up: Changed 5 years ago by nodiscc

I updated the bug at http://code.google.com/p/pidgin-gnome-keyring/issues/detail?id=2 , as the problem is not reproducible for me (Pidgin and libpurple 2.7.9, on Debian Wheezy).

My passwords are immediatly removed from accounts.xml after enabling gnome-keyring plugin.

Can someone check if this is version-related?

comment:26 in reply to: ↑ 25 Changed 5 years ago by BuZZ-dEE

Replying to nodiscc:

I updated the bug at http://code.google.com/p/pidgin-gnome-keyring/issues/detail?id=2 , as the problem is not reproducible for me (Pidgin and libpurple 2.7.9, on Debian Wheezy).

My passwords are immediatly removed from accounts.xml after enabling gnome-keyring plugin.

Can someone check if this is version-related?

i tested it again and now the passwords stored only in the gnome-keyring after a pidgin restart.

comment:27 Changed 5 years ago by BuZZ-dEE

i found a further problem with the irc-helper-plugin. I don't know, if this is related to the gnome-keyring-plugin. the irc-helper-plugin stores the irc-server-password in the accounts.xml file too, but this password are not removed from the accounts.xml file. the text below from the accounts.xml.

<setting name='core-rlaager-irchelper_nickpassword' type='string'>"The_Password"</setting>

comment:28 Changed 5 years ago by rekkanoryo

There is nothing an external password storage mechanism can do for that. Even when/if Pidgin and libpurple have integrated keyring support, it will not solve this for IRC Helper, which is irrelevant because it is a third party plugin and not supported here.

comment:29 Changed 5 years ago by landroni

For info, there is a secret-storage-spec [1] freedesktop.org spec that is in the process of being drafted in cooperation by the GNOME Keyring and the KDE Wallet developers. It might be relevant to our case.

[1] http://freedesktop.org/wiki/Specifications/secret-storage-spec

Changed 5 years ago by grddev

Patch implementing support for keyring plugins without changing existing APIs

comment:30 follow-up: Changed 5 years ago by grddev

The patch just attached implements basic support for keyring integration using plugins (and implements a plugin for gnome keyring). In difference to the gsoc project from 2008, this does not require any changes to existing APIs. It (obviously) introduces new APIs for managing keychains.

With only API extensions, it ought to be easier to integrate, but there might be some tweaks necessary to ensure that the introduced APIs will not be immediately deprecated.

comment:31 Changed 5 years ago by drifter

5 years later, and still nothing of a master password in pidgin.

comment:32 Changed 5 years ago by nodiscc

Confirming this: https://code.google.com/p/pidgin-gnome-keyring/ is working, assuming you have gnome-keyring. Maybe it should be put in the doc.

comment:33 Changed 5 years ago by drifter

That won't work on Windows machines, though. On Windows machines which don't have keyrings, I've found a master password and a password manager with auto-type, like KeePass, to be the best way to handle single sign-on. Unfortunately, Pidgin can't participate because the password dialogs always have the same title, and there is no master password feature.

This may be more dangerous than initially perceived, exposing sensitive information to a wider audience than expected. Most people will probably choose to save their passwords, because it is too impractical to have several accounts in Pidgin, otherwise. Even a computer illiterate, who managed to steal your laptop and logged in thanks to a friend, would find your IMs and email ready and waiting with all your information and power to find and control your other online accounts.

comment:34 Changed 4 years ago by Redsandro

Thank you nodiscc for mentioning https://code.google.com/p/pidgin-gnome-keyring/.

For six million years now - that's about when the first homo erectus requested a master password feature to prevent his friends from trolling with the quick-look method while he was grabbing the joysticks for a game of Caveman Ugh-lympics - the Pidgin team, just like the FileZilla? team, have ignored security that accounts for 95% of the probable causes: People you know and/or people within physical range of your computer when your CIA-class encrypted drive is mounted and unlocked anyway.

And that's the other thing: Only Linux users can setup LUKS or EcryptFS, which is like a few nerdpercent of the userbase. And it's only recent that it's gotten 'easy'. Only Windows Professional or Ultimate support EFS encryption although all non-business laptops and computers are sold with Windows Home. Only 5% of the users can set up the Pidgin endorsed high-grade security that isn't even effective against 95% of breaches.

Although I made up all these numbers, I am concerned with the reasoning behind the project. Relying on highly experienced nerd-tactics for CIA-grade security against the worst of hacker-ninja's from mars is hurting the vast majority end users. Those ninja's are not interested in the conversations with mom of the majority of users. Siblings, schoolmates, collegues, parents, nephews and what not, they are. They will be stopped by a master password. And luckily the pidgin-gnome-keyring provedes that after six million years. For those that are just nerd enough to use Linux, that is.

This kind of security tactics have a strange sense of rewarding that 1% of highly technical users while punishing those that just want to use their computer in a mainstream fashion.

Anyway, the PPA doesn't work out of the box because it was last updated for Natty. You can download the .deb file, and it installs just fine on Oneiric. :)

comment:35 in reply to: ↑ 30 ; follow-up: Changed 4 years ago by bleeter

  • Component changed from libpurple to privacy

Replying to grddev:

The patch just attached implements basic support for keyring integration using plugins (and implements a plugin for gnome keyring). In difference to the gsoc project from 2008, this does not require any changes to existing APIs. It (obviously) introduces new APIs for managing keychains.

With only API extensions, it ought to be easier to integrate, but there might be some tweaks necessary to ensure that the introduced APIs will not be immediately deprecated.

Just had a quick glance across this, seems not unreasonable.

Has anyone else tested this since it was added, or are you all just jumping up and down about a third party plugin which does not much at all to address the original request (that is, *VARIOUS* keyrings should be supported)?

comment:36 in reply to: ↑ 35 Changed 4 years ago by QuLogic

Replying to bleeter:

Replying to grddev:

The patch just attached implements basic support for keyring integration using plugins (and implements a plugin for gnome keyring). In difference to the gsoc project from 2008, this does not require any changes to existing APIs. It (obviously) introduces new APIs for managing keychains.

With only API extensions, it ought to be easier to integrate, but there might be some tweaks necessary to ensure that the introduced APIs will not be immediately deprecated.

Just had a quick glance across this, seems not unreasonable.

Has anyone else tested this since it was added, or are you all just jumping up and down about a third party plugin which does not much at all to address the original request (that is, *VARIOUS* keyrings should be supported)?

The GSoC branch does support GNOME Keyring and KWallet, and I suppose theoretically could support something in OSX as well.

I have done much cleanup and kept it relatively up-to-date. Please check the im.pidgin.soc.2008.masterpassword branch. It likely needs an API review and stuff; I just haven't had the time to kick that off.

comment:37 follow-up: Changed 3 years ago by bleeter

I reckon we should probably support KeePass straight out of our box, too. That'd 'solve' the lack of keyring foo on Windows, yeah?

comment:38 in reply to: ↑ 37 Changed 3 years ago by QuLogic

Replying to bleeter:

I reckon we should probably support KeePass straight out of our box, too. That'd 'solve' the lack of keyring foo on Windows, yeah?

I think Windows actually has a password store, but someone will have to write a plugin either way.

comment:39 follow-up: Changed 3 years ago by Mechanical snail

GNOME Keyring has switched to implementing the Freedesktop Secret Service specification, and KDE apparently plans to do the same eventually, using KSecretsService. So Pidgin could support both by using the Secret Service DBus API (there are some libraries available).

comment:40 in reply to: ↑ 39 Changed 3 years ago by QuLogic

  • Cc Mechanical snail added; Mechanical snail removed

Replying to Mechanical snail:

GNOME Keyring has switched to implementing the Freedesktop Secret Service specification, and KDE apparently plans to do the same eventually, using KSecretsService. So Pidgin could support both by using the Secret Service DBus API (there are some libraries available).

A Secret Service keyring has already been implemented in the branch.

comment:41 Changed 3 years ago by Mechanical snail

Created a wiki page to organize the information: wiki:KeyringSupport

comment:42 Changed 3 years ago by QuLogic

  • Cc zanko mupuf pva Mechanical snail removed

Removing unnecessary CCs on this ticket. If you've commented, you're already CC'd.

comment:43 Changed 3 years ago by tomkiewicz

  • Resolution set to fixed
  • Status changed from new to closed

It's already merged into default branch.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!