[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Persistent password caching (.netrc and .kionetrc)
From:       Dawit Alemayehu <adawit () kde ! org>
Date:       2001-06-12 5:35:32
[Download RAW message or body]

On Monday 11 June 2001 16:40, George Staikos wrote:
> On Monday 11 June 2001 05:13, Dawit Alemayehu wrote:
> > In terms of security, for reading from the file we follow the same
> > requirements set on the ".netrc" file, which is basically that the file
> > must exist and only have "rw" permission for the user.  We also check to
> > see if the current geteuid() matches the uid set on the file.  Also these
> > file must be in the right location of course.  That is ".netrc" must be
> > in $HOME dir while ".kionetrc" must be under the "config" directory in 
> > $KDEHOME...
> >
> > Anyways, in the long run the idea is to unify password caching for all
> > applications that need it. For example, kmail can store any login info
> > provided in the account area in ".kionetrc" using the "preset" keyword
> > and setting the type file.  This makes it easier to allow the user to
> > manage his (her) password from a single control panel config module (when
> > it is designed!).  Also we can store webbased login information and
> > provide similar facilities as Mozilla and IE do in this regards with a
> > very small overhead.
> >
> > Oh BTW, all of this of course is optional as with everything else and
> > will be off by default for the very obvious reasons...
> >
> > What do you all think ? Comments, opinions, ideas ? Is it a good idea to
> > provide a centralized location for storing persistent passwords ?
>
>   I've been pondering this too, because it's basically essential to SSL
> support.  Users will not be pleased to have to type in their password every
> time KDE uses a certificate.  However I won't implement the code to save
> the password until there is an encrypted password registry.  It's just not
> safe. I do have the code for 16 rounds blowfish with variable key length
> checked into koffice and I was planning to abstract it more to make a good
> crypto infrastructure for 2.3.  If you want, we could temporarily move this
> code into a "private" class in kdelibs to use for this.  Then a user would
> input the global password once and all apps could then read the passwords. 
> Ideally this should go in the KConfig layer (I think...) but I guess it
> could go anywhere.
>
>    What do you think about something along those lines?

Yes, this is something that is indeed necessary.  The config dialog could then
give the end user the option to encrypt the password file much like mozilla
does and even perhaps make that the default.  Perhaps this is something that
can even be used generically to enrypt files from konqueror in RMB ? 

Anyways, for now I will just go ahead and write up the format for .kioslaverc
since it is not that different from .netrc with a somewhat more flexiable scheme
and we can take it from there and enhance it as necessary.  Perhaps we will have
the frame work working for 2.3 with some implementation examples :)

Regards,
Dawit A.

[prev in list] [next in list] [prev in thread] [next in thread]