Re: gnome-keyring Passwords freely available after login
- From: Anders Rundgren <anders rundgren telia com>
- To: Karl <karl1982 gmail com>
- Cc: gnome-keyring-list gnome org
- Subject: Re: gnome-keyring Passwords freely available after login
- Date: Wed, 08 Dec 2010 09:42:26 +0100
Hi Karl & Co,
I'm neither a gnome keyring architect or committer but the problem you
mention, for the majority of people already has a solution which is
automatic screen lockup, which not only protects passwords but all
secret/private data in the computing platform.
A (IMO) bigger problem is that serious users of PKI like banks have
no way of specifying a PIN-code for "their" keys, unless the keys
are shipped in smart cards.
In Sweden and in many other countries in the EU and Asia, banks and
governments have created their own soft "keyrings" and schemes for
provisioning those. This "deficit" is not limited to gnome keyring,
it is a platform- wide issue since it is depending on a provisioning
scheme as well.
Microsoft's soft container system where the *user* decides if they want
PIN-protection is in this context completely unusable (hardly anybody
uses it either...) so it is surely not a *NIX issue only.
Anders
Karl wrote:
I realize this is an ongoing and well-worn topic, but I want to weigh in
since I've been a frequent Ubuntu user for some time now. I have a
problem with the way Gnome keyring handles passwords. I understand the
philosophy that a user shouldn't feel more secure than they really are,
and I agree up to the point where security is sacrificed for idealism.
If your car has separate door and ignition keys, you don't leave the
ignition key hanging from the hood ornament simply because no one can
open the door if you always remember to lock it. The one time you
forget, someone drives off with your car.
What I would like to see is simple, although I realize its
implementation is likely not. The user should be prompted for his
password when accessing the keyring, locked or otherwise. I'm not
concerned about the keyring being stolen when my laptop is locked. The
keyring is encrypted, and so is my home folder. My concern is the one
time I forget to lock my laptop when I step away for ten minutes and
someone has complete unhindered access to anything that may be stored in
the keyring. This shouldn't be against the philosophy of Gnome keyring
since it actually does add some measure of security to cover accidents.
If I forget to lock my laptop, it's far less likely my passwords will be
viewed if they aren't readily available. Reducing the likelihood my
secrets will be stolen is an increase in security, even if you might
consider it to be a small gain. Maybe I work around people who aren't
capable of breaking into the keyring, but are nosy enough to open it if
it's unlocked. In that case, the most likely scenario for the keyring
to be compromised will be prevented.
The burden of protecting a user's sensitive data is a responsibility
shared by both the user and the system. The system does the user a
disservice by making no effort to protect this keyring after login.
Right now I'm annoyed by the fact that Empathy won't let me log in to
anything without saving the password in the keyring, which I feel
obligated to remove afterward because, in my opinion, it isn't secure.
There has to be an acceptable way to handle this, and not handling it
because it was originally "by design" doesn't justify being blatantly
insecure. It's a nice idea, but ultimately, it decreases the security
of the system.
At the very least, Gnome keyring should have an option to let me choose
this behavior. It should be my option to choose whether I would like
that one ounce of added security, even if it may feel like two. Those
who don't want it don't have to have it.
------------------------------------------------------------------------
_______________________________________________
gnome-keyring-list mailing list
gnome-keyring-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-keyring-list
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]