monit-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan-Henrik Haukeland
Subject: Re: monit ./gc.c ./monit_http.c ./monitor.h ./p.y ....
Date: Thu, 02 Oct 2003 14:19:08 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Reasonable Discussion, linux)

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:

>> 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 [*]

>> 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. 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
..

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? 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 :-}

-- 
Jan-Henrik Haukeland




reply via email to

[Prev in Thread] Current Thread [Next in Thread]