Re: gnome-devel-list digest, Vol 1 #882 - 4 msgs

Message: 4
Subject: Re: Current network-password-saving feature needs improvement.
From: Sean Middleditch <elanthis awesomeplay com>
To: Hema Seetharamaiah <hema seetharamaiah wipro com>
Cc: desktop-devel-list gnome org,
	gnome-devel <gnome-devel-list gnome org>
Organization: Date: 18 Jul 2002 11:46:37 -0400

On Thu, 2002-07-18 at 11:17, Hema Seetharamaiah wrote:


Currently, the user needs to setup the network/http username and
password via the network preferences capplet. Only if this is done, the
user can use gweather, stockticker and nautilus (browser part).

This password is saved into the user's gconf in *plain text*. It's an
issue of privacy (and security) where somebody ( root for one ) can
easily get access the user's network password.

Shouldnt it be stored in an encrypted form, so that at least, it is not
so easily readable?

I don't think this really could be encrypted.  I mean, it eventually has
to be unencrypted.  Therefor, anyone who could read the encrypted
password could decrypt it, since the algorithm would be freely available
under the GPL/LGPL per the gconf source license.

True.  But it could (and should) be shrouded so that
casual display won't reveal it.  It won't prevent
any serious attack, but it deals with someone who
_accidentally_ sees the material.  It's easy to do
and still worthwhile, even though its help is only

Second, if you do not trust root, do not use the machine.  Root can
record all your mouse clicks, keyboard presses, network traffic, etc. You are completely at root's mercy no matter what. Sure, go ahead and
type in the password every time; root can just record what you type in
if she so wishes (of course by setting up a program or X modification
ahead of time).

Agree.  If you can't trust root, you're mostly dead.
One-time passwords help, but root can forge ANYTHING.

But there _is_ a threat model where this makes sense:
you trusted root, and then someone stole your hard drive
(e.g., it's a laptop and the laptop was stolen).
Encrypting filesystems are one way to deal with this,
but that's a heavy hammer to wield if the only thing
you're trying to protect is passwords on other systems.

And more importantly, shouldnt there be an additional option where the
user gets a choice to *not* save the password and later on, when he
connects to the http proxy the first time, he is prompted for the
password? This password could then be retained for the rest of the

This, again, really isn't that useful, for the reasons I stated above. You would be complicating your experience and not increasing your
security by any substantial amount.  So long as other users can't read
your password (the gconf store used is user readable only, correct?) you
aren't in any more danger storing your password than you would be

Perhaps the only decent addition that could be made is require all
passwords in gconf to be truly encrypted with a master password.  Then,
on login, the password could be queried (or a PAM or GDM module could
use your login password as the master password).  This way, simpler
attacks that simply read your files without installing software would

Actually, THIS IS A _GREAT_ IDEA!!
Doing it through PAM or GDM would make the whole
process more secure and quite simple.
The "ssh-agent" program is somewhat similar - it
stores keys for others.  Perhaps it could be modified
to support this approach and the needs of others?

My big request is that, if you do this, please make
sure the result is NOT tied to GNOME.  I'd like to
see the KDE folks adopt exactly the same solution,
so that there is only ONE mechanism that solves the
problem for everyone.

Are you interested in discussing this further?
I don't know if this group is the right group, other than
for the specific issues for GNOME.  Certainly Mozilla
has similar issues (they shroud by default, and can
optionally encrypt with a master password, if I
remember correctly).

--- David A. Wheeler
    dwheeler ida org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]