Re: [PHPiCalendar-DEV] Real admin page

[Wesley M. <we...@we...>]

Hi Nicolas,

>  Ok.
> The idea is to let just the admin modifying those parameters, under  
> the secure admin area.
> So if apache is well configured, it would be any problem.
>
> I'll work on it next week, when I'll be less busy, and call you  
> back for analysing the effectivness.

Just to be clear, my opinion is that we shouldn't make the contents  
of config.inc.php editable or viewable from a web page. I do not know  
if any of the other developers have an opinion on this one way or the  
other.

>> I still don't understand your question, sorry?
>
> Login/pass seem to be used only for admin purpose.
> And according to the code, 'admin' is an apache authenticated user,  
> so i'm not sure, it's usefull to duplicate it (and in a clear format).

There are different logins at work here. The login for the admin page  
is not an HTTP authenticated user. HTTP authentication is used (at  
least as far as config.inc.php is concerned) to identify users for  
access to different calendars.

The login for the admin page may either be authenticated against the  
username in config.inc.php or against an FTP server (which I have not  
tried myself) and is used to determine who can upload calendar files.

BTW - I just noticed the default is for admin to be 'yes'. I think it  
should default to 'no'. Anyone else have opinions on this?

>> I don't see much alternative to having a plaintext username/password
>> for the admin login. You want to do a client-side one-way hash or
>> something? Or something more complicated like SiteKey?
>
> Yes a ('homemade' ?) hash or a web base auth. as we already use in  
> 'publish.ical.php'.

HTTP authentication is also passed in the clear unless you are using  
SSL. So that doesn't give you any benefits over the current plaintext  
login. Turning on HTTP authentication also requires more web server  
privileges than some people have. So moving from the current username/ 
password text login to an HTTP authentication is a bad idea in my  
opinion. It will work for less people, and not give you any security  
benefits.

A client-side hash is an interesting thing to consider. But to do  
this securely, you need to make it a one-way hash that is different  
every time, based on a token provided by the server. And the server  
needs to manage the token(s) that were distributed to allow only one- 
time use at the client. Otherwise you can just replay the captured  
hash and you're in. Those same tokens need some sort of expiration.

If you want to try and tackle implementing something like Diffie- 
Hellman (which I think still has problems, but I always remember the  
name) then you're welcome to. A bit of overkill in my opinion though.  
We could ask for peer-review of the PHP code at sci.crypt or something.

Later,
--
Wesley Miaw
we...@we...