Re: Current network-password-saving feature needs improvement.

[Sean Middleditch <elanthis awesomeplay com>]

The way I've seen it done on UNIX the most is PAM session modules that
launch daemons, mount remote file shares, etc., using the password
provided when logged in.

I suppose writing a very simple daemon that creates a user-only socket
in $HOME and gets the password from PAM could be written.  Then any
application could open the socket, get/store passwords, etc.  Of course,
then you'd loose network transparency.

Otherwise, you need to start writing all your apps for Kerberos, which
is (using a different protocol, albeit) how Windows gets it's single
sign on, as I understand it.

On Thu, 2002-07-18 at 17:26, David Wheeler wrote:
> 
> The more I think about it, the more useful a
> general "password saving" feature appears
> for open source operating systems.
> 
> All web browsers need to store passwords for
> later use, and obviously more and more applets
> need to store passwords for later use too.
> "Shrouding" doesn't help protect against
> people who steal your laptop.  Having
> "master passwords" helps, but currently people
> have to enter multiple master passwords
> (one for GNOME, one for SSH, one for Mozilla, ...).
> That's annoying.
> 
> It'd be great if there was a simple, standard mechanism
> to support "single sign-on" for Unix-like systems.
> Just log in once, and the system can automatically
> encrypt and store all the other passwords you'd like it
> to using your login password.  Sounds user-friendly to me.
> 
> Perhaps a small "secret server" could be created
> that ran on behalf of a user, and could get and store
> secrets on behalf of that user.
> Here are a few ideas:
> * Given an application name and key it could get a secret
>    (e.g., "I'm Mozilla, what's the password for
>     bogus wazoo com?" returns "sugob").  That way you could
>    disambiguate between different applications.
>    Perhaps you could limit requests so only certain applications could
>    get certain keys, but you'd have to find a way to
>    trust the application name - I'm not sure how to do that
>    nicely.
> * Given an application name, key, and secret, it could be
>    stored.
> * It should be startable via PAM or GDM, so the
>    login password could be used to generate the
>    encryption key.  However, the password itself shouldn't
>    be encryption key, since if a nasty application takes over
>    the machine that would reveal the login password.
>    Thus, use a cryptographic hash of the login password plus
>    a nice large salt (which is stored as plaintext in the
>    keyfile)... an attacker gets the other passwords, but
>    possibly not the login password.  By only using the
>    password and salt to determine the encryption key, the
>    master key file could be later moved and used on other machines.
> * It shouldn't REQUIRE being started with PAM or GDM - if
>    it's not started by login, or the user wants to use a
>    separate password when accessing the keyfile, then it should
>    gracefully ask (like ssh can do now).  Thus, the master keyfile
>    should have some indicator that says "ask separately".
> * Perhaps start with ssh-agent.
> * It should be small and work for EVERYONE.  Then Mozilla,
>    GNOME applets, etc. should all be modified to work with it
>    when available.
> 
> 
> Comments?  Thoughts?
> 
> 
> --- David A. Wheeler
>      dwheeler ida org
> 
> _______________________________________________
> gnome-devel-list mailing list
> gnome-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-devel-list