Since I published my website address in my signature, I get sometimes possible hacking attempts to find GT applications on my site, especially the admin.cgi file. Interesting, eh?
Once the admin.cgi can be safely renamed, this hacking danger goes away. Thanks to this, I was able to avoid hacking attempts until now.

However in GCommunity, the admin login interface is not separated from user login interface. Hacker just goes to community.cgi and can start hacking.
It is a good point, that the admin username can be changed to anything you want.

I know, I suggested already the user & admin login interface separation. Now I just wanted to mention these facts above, and my final thoughts below...

IMO, an admin login needs the following features:
1) ability to login admin through a different place, like user login, e.g. admin.cgi
2) ability for user to rename admin.cgi, to even stop hacking attempts at the beginning (by default, admin.cgi is fine)
3) admin username should be changeable (yes, this is available already)
4) ability to set secure SSL URL for admin.cgi in community.conf, like this:
$admin_cgi_name = "admin.cgi";
'secure_admin_cgi_url' => 'https://www.site.com/cgi-bin/gcomm/<%admin_cgi_name%>'
5) additionally allowing the user on login page to choose wether he/she wants to login through secure SSL or normal connection, would be a very good point (the solution, how the login was solved on www.sourceforge.net is a reference (at least for me), which shows how to do something in a good way, and GCommunity - not necessarily - but may follow this example.)

Best regards,
Webmaster33

---

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

Most of those hack attempts, I'm willing to bet, are simply people checking to see if you have an admin.cgi script which isn't password protected. Sadly, not setting an admin username/password is something that happens many, many times. In many cases it is because the admin cannot password protect the admin panel without the intervention of their ISP - for example, on IIS servers which do not support .htaccess files, or Apache configurations where the htaccess files have not been enabled.

Because of this, we want to get away from having server-dependent password protection, and so we are changing the way our scripts handle the admin process to make logging in as an admin essentially no different than logging in as a user. Community doesn't quite do this - logging in as an admin is not, technically, logging in as a user, but still through the same login form to try to keep things more centralized. However, the point is that the admin area is now always going to be password protected, which is a very good thing as far as security goes.

Given the "old" admin panel way (Links SQL, Gossamer Forum, etc.), renaming admin.cgi to something else really does not really improve security at all. What is protected is not the admin.cgi file, but rather the admin directory as a whole. Even if you have renamed admin.cgi to notadmin.cgi, people attempting to access admin/admin.cgi will not notice any difference at all - they'll still be given a password prompt, which they can still attempt to hack. Assuming they do manage to break through the admin/ password, all they have to do is load the configuration file to find the new admin.cgi name. Although it is possible to rename the entire admin directory, doing so is no simple task, and isn't really supported by us.

So I don't really see that the current security model is significantly weaker than the old one. In many cases it is much better and is certainly more convenient for admins. On a final note, Community's password are actually significantly more secure than the typical .htaccess/.htpasswd ones. This is because Community stores passwords using an MD5-based encryption, while the one's typically used in .htpasswd files use a much simpler crypt() encryption. Suffice it to say that breaking a crypt() encryption through brute force is much simpler than tackling an MD5 one.

---

Jason Rhinelander
Gossamer Threads
jason@gossamer-threads.com

That is an issue I don't understand!

I have a LinksSQL-admin.cgi, a Forum-admin.cgi, a GTMail-admin.cgi, a DBManSQl-admin.cgi (this are all separated admin areas) and when using community I will have no separated admin-area/admin-login but have to visit my user-pages to log in as an admin.

I think you can turn it as you want...there is no centralization at all for an admin. The only centralization issue using community is, that you have to login using the same form as your users!

If you don't want to use .htaccess why not providing a from the users-login-form separated web-based admin-login-form which is in another place/folder??!

Regards,
Manu

Shopping Portal Shop-Netz.de® | Partnerprogramme | Flugreisen & Billigflüge | KESTERMEDIA e.K. | European Affiliate Marketing Forum.

Maybe. We can not know that for sure.

I did not say, that it is bad. Of course, I would accept & aggree your reasons about that.

Yes, I aggree. But I never told this is bad. My problem is with common user & admin login...

I never told such thing.
I said, using common user-admin login is weaker, than having separate user & separate admin login.

Jason,
the main point in your answer was to compare old htaccess based protection with the new common user-admin login interface. I aggree with your reasons, but I was talking about common user-admin login problem.
I know the current user login system is secure, especially if we use the MD5 password hashing.
However I'm maximalist. We know, that before the password is hashed with MD5, it's sent in plaintext format through the net, which can be captured, that's why I suggested the SSL support (optionally).
Also it's a bad thing, that people knows, where the admin login interface is. It's not avoided with the common user-admin login interface. Yes, I know, user can change the admin username, but IMO this is not enough. Having the admin login interface separately, gives the possibility for paranoid webmasters to increase the security by renaming the admin login script.

I described the 5 main features, what IMO a login interface may need to have, and listed in my original post (the last 5th point is also user related).
Could we analyze & discuss those features?

Best regards,
Webmaster33

---

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

You *DO* need to make sure that the /private directory is *really* private.

Not every server config allows "overrides all", so just plopping in an .htaccess file doesn't always work. Also, not every server uses '.htaccess'.... some have renamed it to make it harder to hack.

For security reasons, I have my servers set so that directory configurations are done in the httpd.conf file, not by .htaccess.

I made this decision years ago, so that hidden files, old security holes, etc wouldn't be laying around. Also, there is a slight performance increase if the server doesn't have to look for the .htaccess files.

Ofcourse, this works because I rarely make changes to the server configurations, and have a fairly standard protected directory structure.

I just checked my /private directory, and it wasn't private. There was an .htaccess file, but I had to add the configuration options into my server configs.

*THIS* is a security hole for the unaware.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

I've barely touched Community (just installed it and poked around a little while I'm waiting for final release) but is there a reason you can't keep your private directory above the document root and therefore much less accessible? That was what I did when installing it seemed to work, although again I admit I have done very little testing.

---

Fractured Atlas :: Liberate the Artist
Services: Healthcare, Fiscal Sponsorship, Marketing, Education, The Emerging Artists Fund

This is also how I have installed it, and this is probably the best way. Like this, there is no .htaccess problem at all.

Ivan
-----
Iyengar Yoga Resources / GT Plugins

It's just in the "standard" GT layout, the protected/private areas were under the admin, and off the install root.

If there is a change in this, install instructions, and a heads-up, and other such things should be given.

Remember, a *lot* of different people are going to be installing under a lot of different circumstances.

In future set ups I'll probably move things out of the web tree, but it starts to need another set of "rules" for server layout and administration.

For one site, it may not be an issue, for hundreds, it is a big one.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

Hey:

I just cp'd private from under comm/ to above public_html... and then I changed the path in the admin, but it did not take. Do I have to re-install to get the new path to take?

Thanks!
dave

Big Cartoon DataBase
Big Comic Book DataBase

What was the error?

The (new) "path to /private" did not take, when just changed in the admin. Here is some error:

[Tue Feb 11 10:11:00 2003] [error] [client 12.344.121.366] Premature end of script headers: /path/to/public_html/comm/community.cgi

Can't locate Community.pm in @INC (@INC contains: /path/to/public_html/comm/private/lib



Note that /path/to/public_html/comm/private/lib SHOULD be /path/to/private/lib if that had taken...

dave
dave

Big Cartoon DataBase
Big Comic Book DataBase

You need to change the "use lib" line in the cgi scripts.

Paul:

Thanks!
dave

Big Cartoon DataBase
Big Comic Book DataBase

I submitted a bug about this yesterday, after reading your post. You are correct, we should recommend installing the private directory outside of the document root, and hopefully the next version will have the change to documentation and the install blurb. I've also recommended that there be no default value, since that way it requires users to read the option and enter something, rather than just hitting next with the default (which is typically in the cgi-bin, especially if installing via CGI).

---

Jason Rhinelander
Gossamer Threads
jason@gossamer-threads.com