Re: CIPE source code modifications|
Damion Wilson <dwilson,AT,ibl,DOT,bm>|
Wed, 19 Mar 2003 00:41:07 +0100|
Yes. I have hated that there was the need to store the thing in cleartext.
This is why I want to switch to the URI style mechanism. This way, you could
(eventually) utilise keys that were generated elsewhere. If a password is
going to be used, it should only be used to get at , say, a pgp encrypted
keyfile ala pgp:/a:\statickey.asc and should be prompted for specifically,
not as part of the Control panel static key field. That's basically my
argument here: that the Control Panel is not the place to do this stuff.
You're absolutely right about that. That's why I want to get this stuff out
there, ergo the rationale for replacing the applet with something else.
However, on Linux, the superuser must still edit the config file with the
static key clearly visible. The file is not accessible by any other user, but
someone can still look over the administrator's shoulder.
I don't want the development direction going down the path of changing the
existing Control Panel applet too much because its whole approach is wrong
vis a vis security and protecting the static key. I also don't want a fork to
happen at this point because some of this stuff may change cipsrvr.exe. I do
want all of the input and ideas, though.
Perhaps this stuff should be handled by IPC between the "Manager" and the
running cipsrvr. That way, we could control access to the whole shebang with
a password and encrypt everything. Cipsrvr could then be left running all the
time but be unable to access the control information without the password
provided by the user.
Input, anyone ?
On Tuesday 18 March 2003 06:49 pm, you wrote:
> first let me thank you for your great work on CIPE for Windows! It is
> extremely useful for our customers and ourselves.
> On Tue, 2003-03-18 at 21:15, Damion K. Wilson wrote:
> > 2. I disagree with the asterisk representation. It's too hard for the
> > administrator to confirm that he/she has it done right.
> In case you suspect that the key is wrong you can transfer the key using
> cut & paste. But even this can be improved by reading the key into the
> input field from a file (e.g. the options file from the peer Linux
> system) -- Carsten is working on this.
> > I repeat it is NOT A
> > PASSWORD AND IT IS STORED IN CLEARTEXT !
> I've done several evaluation installations of CIPE on Windows for
> customers during the last weeks. The users' major complaint is that the
> encryption key is too easy to retrieve by non-authorized persons. The
> first idea for a solution was to display the asterisks instead of the
> key. Now it's much better: the key stored in the registry is protected
> by a passphrase.
> > If you have problems with this
> > representation then you need to chase it up with Olaf. I am strongly
> > disinclined to merge this feature as the stated mandate of this project
> > is to follow Olaf's direction.
> The situation on Linux is pretty much different than on Windows. On
> Linux, there's no world readable registry where the key is stored.
> > It appears that the way forward with this is pkcipe.
> Even with pkcipe you have to protect the private key somehow.