Re: monit ./gc.c ./monit_http.c ./monitor.h ./p.y ....

[Christian Hopp]

On Thu, 2 Oct 2003, Jan-Henrik Haukeland wrote:

> Christian Hopp <address@hidden> writes:
>
> > The problem is, in http basic auth the passwords are actually
> > cleartext (or base64) so the what for should we encrypt the passwd
> > for?
>
> I think you just answered this yourself below:

Did I?

> >> If so, you must encrypt all password in monit with this algorithm
> >> and also encrypt submitted passwords and compare the encrypted
> >> password strings.
> >
> > Easy way... we store in one digest format (e.g. user can choose which
> > one, set pwdigest [crypt|md5|none]) internally and in htpasswd files.
> > The browser does still transmit cleartext.  So we digest the received
> > pwd and compare it against our digested pw-db.
>
> Passwords recieved in base64 encoding over Basic Auth. must first be
> base64 decoded to cleartext and [*] then encrypted with the same
> one-way hash algorithm choosed in monit (i.e. the one choosed in set
> pwdigest) so we can compare the end result (the digest string) and if
> they are equal, the password match.
>
> > The only thing that is left then... how do we deal with the cli
> > program of monit.  We can send e.g. the digested pw.  Or... the cli
> > needs a more complicated connection mechanism.
>
> See [*]

But if monit doesn't have a cleartext password, it can't be sent to
the server.  The server side to big deal... the client side is the
problem!

> >> I know it's a bit late to ask this question, but what exactly is the
> >> benefit of using an external htpasswd file?
> >
> > You can use it as a central source for your web service passwords.  It
> > is easier to maintain them centrally.
>
> Hmm, I know it's bad to ask these questions now, when you have
> developed the code, but.. I'm not sure how usefull it is and if many
> will use this feature? The username/password you use to access the
> local intranet will hardly overlap the one used for accessing monit,
> it might, but my guess is that most will perceive monit and other web
> applications as different systems and maintain them seperately. There
> is one, maybe, usefull thing, that is encrypting passwords, but this
> could also be done directely in monitrc.

But then you have to maintain the passwords by hand... using htpasswd
you can iuse apache's htpasswd program to do the dirty work
(encrypting...).

> What I originally thought this feature meant, (obviously I
> misunderstood and I must admitt, I didn't think much about it
> either) was that you could limit access to some pages in monit
> similar to something like this in apache:
>
> AuthUserFile /../.htpasswd
> <Limit GET POST>
>         require valid-user
> ..

Aehm... you mean .htaccess?

> This could be an idea, to only allow certain user to access the
> url-path /apache, so not everyone could start/stop this process. But
> of course this would be more complicated and very hard to solve for a
> monit client (which user/passwd should you choose?).
>
> I'm simply uncertain if providing the ability to have user/passwd in
> an external htpasswd is all that useful and if it justify adding all
> this extra code?

The htaccess stuff is comparably little code.  Just the hook to "ALLOW" and a 
simple parser for "colon separated" username/passwd entries.

> But then again I'm not a very advanced user of monit and absolutely
> not a sys. adm. I'm not saying that we should rip out the code from
> monit, but maybe at least think about it :-}

As long as it's still cleartext it might be kinda bogus but as soon it
might contain crypt/md5 passwords it's more handy to have htpasswd to
maintain the passwords.


CHopp

-- 
Christian Hopp                                email: address@hidden
Institut für Elektrische Informationstechnik             fon: +49-5323-72-2113
TU Clausthal, Leibnizstr. 28, 38678 Clausthal-Zellerf.   fax: +49-5323-72-3197
                             pgpkey: https://www.iei.tu-clausthal.de/pgp-keys/