Possible Kolab LDAP configuration information disclosure

Thomas Lotterer thl at dev.de.cw.com
Wed Apr 21 09:19:17 CEST 2004


On Tue, Apr 20, 2004, Martin Konold wrote:

> Am Tuesday 20 April 2004 04:03 pm schrieb Luca Villani:
> 
> > > What do you gain? The above encoded pw can also be used to replay...
> >
> > The above encoded pw is an SSHA encryption of the string
> >
> > 	averystrongpassword
> 
> What is the gain? (It can be abused also in the encoded form)
> 
Nothing. I agree with Martin.

It is a unresolved problem in computer science that any application
doing automated authentication using a secret must have the secret
available. The simplest way is to store it for reading which is what
Kolab does. Using encryption does not help anything. If the password
can be used in the encrypted form it is as valuable as the uncencrypted
form. If the legal client application must decrypt it, anyone having
control over the legal application has equally access to the target. If
the algorithm and decryption keys are known, access to the target is
possible even without having control over the legal client application.
Same issue if the secret is not stored but generated. Things can be made
harder if the password is stored in a remote location, which grants
access to the target to the persons who control the remote storage. This
game can be played endless without ever finding a solution. It is only
possible to make it harder. The closest approach to a solution I ever
heared about is a distributed store of pieces that make up the secret. I
have discussed this with a member of the OpenSSL team in the past when
it came to storing certificates securely. We came to the conclusion that
there is no way doing it.

A simple and still close to solution approach is to protect the storage
from being read by unauthorized persons. Which should be done.

--
Thomas.Lotterer at cw.com, Cable & Wireless




More information about the users mailing list