GNOME Bugzilla – Bug 531603
Password storage is security risk
Last modified: 2018-07-12 00:12:22 UTC
I would like for passwords to be stored in the gnome-keyring rather than in a plain text file in your home directory. This is especially important for blogspot users since blogspot.com is partnered with gmail. Gmail users therefore automatically have a blogspot account which shares its password with their (often primary) gmail account, and perhaps unlike blog passwords, gmail passwords are very often the same password used for main user accounts on the users computer as well. In fact, it's the most common password to double as a user password, meaning that now a users primary account password is stored in plain text in their home directory.
I'd like to add that while the new update that allows passwords to be displayed in asterisk characters is appreciated, it is still misleading and amplifies the risk posed by this shortcoming, since users are now less likely to realize their password is unprotected. If keyring integration is not possible for the next version, an easy short term solution would be to make the blog applet functional in the absence of saved passwords, and allow the user to enter his or her password each time we try to submit a new post.
Feel free to provide a patch…
Are gnome-blog patches still being reviewed? After the Blogger Atom API one in bug 151291 went unreviewed/commented upon for a while, I stopped submitted them. I had a hacky one for keyring storage that I could clean up, though :)
Created attachment 146713 [details] [review] Patch moving passwords into GNOME Keyring Here's my first attempt. It's my first time working with GNOME Keyring and I don't use Python much, but it works for me so far. I'll be glad for any advice and suggestions.
Created attachment 146714 [details] [review] Patch moving passwords into GNOME Keyring Oops, I failed to git add a file. Here we go with the missing blog_keyring.py file too.
Created attachment 146715 [details] [review] Patch moving passwords into GNOME Keyring This time excluding superfluous changes from a different patch.
As security issues are to be taken seriously confirming this as a bug and setting importance high.
Created attachment 155578 [details] [review] Save password to gnome keyring instead of gconf. This patch differs from Richard's previous patch by * structure * only password is saved to keyring, not username and password * far less writes to keyring (every key press vs. focus-out-event when password has changed)
Review of attachment 155578 [details] [review]: ::: blog.py @@ +59,1 @@ The gconf_prefix allows you to configure multiple blogs with a different gconf_prefix. Your change makes this impossible, you cannot have two different blogs anymore (by using a different gconf_prefix). @@ +69,3 @@ + except gnomekeyring.DeniedError: + hig_alert.reportError(_("Error retrieving credentials"), + _("Unable to retrieve credentials from Gnome keyring.")) GNOME, not Gnome Not sure if this message is understandable enough for users. @@ +79,3 @@ + else: + hig_alert.reportError(_("Error saving credentials"), + _("Attempt to save credentials in to Gnome keyring failed. Please enter password again.")) Will that really happen (Please enter password again)?
Tommi, is there any particular reason you'd rather not save separate passwords for separate blogs+users? Yah, focus-out-event is probably a better way, as I suppose it will be triggered even if I alt-F4 or escape the window. Is there any point in modifying my patch for that, if Tommi will consider differentiating blogs' passwords (as I use GNOME Blog for multiple accounts).
Richard, didn't really think about gconf_prefix and it's usage. Reworking the patch. The whole multiple accounts approach might be reworked. It's not nice at all, don't you think? Idas?
So, gconf_prefix is usually /apps/gnome-blog if gnome-blog-poster is called from the command-line or a launcher, but its panel applets get distinct prefixes, enabling someone to have multiple GNOME Blog applets that are setup for different blogs. So, historically, GNOME Blog stores a single blog type, username, and plaintext password per prefix (and thus per panel applet). I sort of violate that in my patch, by storing passwords by blog type and username in GNOME keyring independent of which GNOME Blog configuration you use. I like that, because * it makes the saved passwords available to any instance of GNOME Blog if changed to use that blog type and username * it preserves password configurations if its blog type and username aren't currently configured for any particular GNOME Blog instance (but might be again in the future) * it's very useful when you're using GNOME Shell and not GNOME panel so you're just launching gnome-blog-poster and only have one configuration that you want to switch between. I suppose the other solution would be to use the gconf_prefix as an attribute for the saved passwords, so you'll save one password specific to a given active configuration. ---- Regarding multiple accounts, perhaps an account manager ala Empathy would eventually be nice, but probably a cause for a new bug. I suppose there are two levels, accounts and blogs for that account (with services that allow multiple blogs on the same account, like Blogger). I have a few local, unpolished patches that make managing multiple blogs for the same account easier. At the very least, regarding the preferences menu, I'm not sure that the protocol or address for a blog type always have to be displayed. Perhaps hiding the fields until you select a Blog Type that actually lets you edit them would be nice. (Here are my local patches, for reference: * adds a blog selector on the post window (though we want to keep that window simple) * in the preferences pane, automatically lookup the list of blogs for an account if a password is detected (but only when you open the pane; though it would be better to do then and on focus-out of the password field) )
gnome-blog is not under active development anymore and has not seen code changes for many years. Its codebase has been archived: https://gitlab.gnome.org/Archive/gnome-blog/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.