Gossamer Forum
Home : Products : Links 2.0 : Discussions :

Do you want Password Protection in the next Links version?

(Page 1 of 2)
> >
Quote Reply
Do you want Password Protection in the next Links version?
Am I the only person that wants and expects integrated password protection in a Perl script? Would you like to see it in the next version of Links as much as I would?

I understand the correct way to protect files is to CHMOD the directories, et cetera, et cetera, but how about us Windows cry babies? Why should we have to trouble our ISP's to password protect the Links directory; be forced to run FrontPage extensions and install child webs; or add kludgey code fixes, just to protect an excellent but vulnerable Links program?

I know this isn't rocket science. However, two constants in human existence are laziness and addiction to our pain. So, many of us just put off the implementation of password protection schemes and languish in torment, rather than do "the right thing" and fix the protection hole(s) in Links. Wouldn't it be much easier if GTI just added a little password protection code in the next version? This would at least offer some sort of quasi-password protection, like every other links program on the web has?

What do YOU think? Do you want to see Password Protection in the next links version... or is it just me?

------------------
Lenon.com Homepage
www.lenon.com
------------------
Lenon.com Links Page
See our "Snap Interfaced"
Gossamer Threads v.2.0
www.lenon.com/links/pages
------------------






Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
As stated many times, password protecting the script will do nothing to protect the data. Only the script gets protected. There is just no substitute for server protection instead of script protection.
Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
You're right Bobsie, for example, by searching for email.db on hotbot, I came up with alot of interesting stuff that email harvesters would loved to get their hands on. Just might as well get a UNIX server.

Dear Mr. XanthisHP - one of the first things to remember about password protection is never to use the same password in multiple places Smile Snap Head

[This message has been edited by XanthisHP (edited June 27, 1999).]
Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
  
Quote:
As stated many times...

Yes, I see, Bobsie. And, I have heard it parroted many times. But, that begs the obvious.

Put another way, "Do you want the scripts password protected in the next Links version?"

While I can see some potential problem with a spammer getting ahold of our email.db file, does it really make any difference if they procure our catagories, links, or url data files, given that we are freely volunteering this information anyway?

I believe our major concern is someone getting into the administration feature and wreaking havoc, et cetera.

------------------
Lenon.com Homepage
www.lenon.com
------------------
Lenon.com Links Page
See our "Snap Interfaced"
Gossamer Threads Links v.2.0
www.lenon.com/links/pages
------------------









[This message has been edited by Snap Head (edited June 27, 1999).]
Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
Just a thought: Wouldn't it be possible to have the /data directory in a non-public directory ('above' the www or public_html or whatever)? This should give you poor NT-users
some measure of security, shouldn't it?

I'm on a UNIX-server and use .htaccess so I haven't tried this out, but I cannot see why it shouldn't work.

John
Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
Yes, that would work just fine. As a matter of fact, we do that on our *NUX boxes.

I should clarify one point. We have sites on a UNIX server, FreeBSD server, and our own Slackware server. We also run a Wildcat! BBS on a dedicated Win95 server, locally. It just so happens that we are using a WinNT server for own domain.

But, back to your point - yes, this would work, but ISP's are usually very reluctant to allow access in a non-public area on the server-side. Our ISP did this for a while, until one of their German clients uploaded a variant of the Melissa Virus to their server. It executed at midnight and erased the WinNT kernel. It took their server(s) down for three days as well as half of the Eastern US UUNET.

So, I don't think this is a viable fix for a lack of password protection in Links, in most cases.


------------------
Lenon.com Homepage
www.lenon.com
------------------
Lenon.com Links Page
See our "Snap Interfaced"
Gossamer Threads Links v.2.0
www.lenon.com/links/pages
------------------








Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
     
Quote:
There's no excuse as to protect your cgi scripts and not your data files... Ignorant people will post over and over for password protection their scripts (sic).

Ignorant people, huh? XanthisHP, I hope you can take a harmless joke in the spirit of friendship and brotherhood Smile I am in no way being malicious - just trying to prove a point.

I hope you'll enjoy your upcoming UNIX web server but they're not a whole lot more secure than a properly setup WinNT.

------------------
Lenon.com Homepage
www.lenon.com
------------------
Lenon.com Links Page
See our "Snap Interfaced"
Gossamer Threads Links v.2.0
www.lenon.com/links/pages
------------------

[This message has been edited by Snap Head (edited June 27, 1999).]
Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
Snap Head,

Quote:
While I can see some potential problem with a spammer getting ahold of our email.db file, does it
really make any difference if they procure our catagories, links, or url data files, given that we are
freely volunteering this information anyway?

We are not giving anything away. People who want to copy our categories and links have to really work at it. At least, that is the case on my setup because:

1. I password protect the directory (not the script).

2. All user accessible scripts will only execute if one of my web pages is the referer.

3. No link on my pages has a direct URL. They all are passed to jump.cgi in order to be brought up. So even if the source code for each page were copied, it wouldn't do much good unless the person manually converted each link in the source based on the URL that comes up when manually accessing the link from my page (jump.cgi will not work off my domain).

If the go through all that trouble, they are welcome to what they can get but they definitely will need to work long and hard to do it.
Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
Hey Snap Head, great joke you done to on my banners on my site. At least you didn't mess up anything else. Smile No harm done.

BTW, I still haven't even finish that site you got in yet. I just got my domain transfer yesterday. You were lucky. . . Wink

------------------
www.techdevelopers.com
ASP, HTML, CGI, Flash, and more!



[This message has been edited by XanthisHP (edited June 27, 1999).]
Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
 
Quote:
Why should we have to do all this work to password protect GTI's Links program?

Because you are under a misconception. You are not protecting the script per se. You are protecting the script and all its data. There is just no way that anyone can protect the data files by including passwords in a script. While server protection via htpasswd and htaccess is not perfect, it is far better than leaving a big security hole for the data. The scripts will do absolutely no good if your data files are overwritten or deleted.

Password protecting the directory covers everything.
Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
Bobsie:

>> 2. All user accessible scripts will only
>> execute if one of my web pages is the
>> referer.

I've been running Apache for years, and have tried all kinds of directory/file/bandwidth-thief protection, but I've never been able to get this type to work reliably. I've tried dozen's of code snippets, patches and such. I've always come across problems with legitimate requests being blocked at some point.

How do you make yours work?

Because of the heavy graphics/image intensive nature of our product, limiting bandwidth thieves has been #1 on our list.

Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
XanthisHP, thank you for being a good sport. As I said, it wasn't my intention to be malicious. I think this world needs more brotherhood and friendship, and less confrontation.

Security on the web, no matter how well planned out, is mostly an illusion. I simply thought this would be the best way to prove it. And again, thank you for NOT taking my illustration of this point the wrong way.

Now, back to the topic.

We've tried a lot of CGI programs on our site. As a rule, they all contain some sort of password protection scheme. The best ones, in my opinion, require both a "name" and "password". The worst ones are those that contain NO password protection at all.

Unfortunately, Gossamer Threads Links falls into this category. I think we all agree that GTI Links is the best links program available. And, I think we all agree the proper way to password protect our files is through server-side protection schemes.

But, I think I've pointed out that as well intentioned as one may be, server-side protection isn't, in itself, the answer.

The fact that I 'sniffed out' XanthisHP's password on this hideous UBB program in less than 5 minutes, as an example, proves this point.

So, why don't we just forget this line of logic. Server-side protection isn't the end-all in password protection. Neither is password protecting scripts only. And, I don't think it's just "Ignorant people" that continually request it Smile But, it's a start, isn't it?

------------------
Lenon.com Homepage
www.lenon.com
------------------
Lenon.com Links Page
See our "Snap Interfaced"
Gossamer Threads Links v.2.0
www.lenon.com/links/pages
------------------










[This message has been edited by Snap Head (edited June 28, 1999).]
Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
I put the referer check that is in add.cgi already in the other scripts as well. If the referer does not come from my site, the scripts will not work. Now I know that referers can be falsified if one knows how, but so far, I haven't seen any problems with it.
Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
Bobsie,

Pugdog's remarks bring up another point:

Quote:
I've been running Apache for years, and have tried all kinds of directory/file/bandwidth-thief protection, but I've never been able to get this type to work reliably. I've tried dozen's of code snippets, patches and such. I've always come across problems with legitimate requests being blocked at some point.

Why should we have to do all this work to password protect GTI's Links program?

I'll bet that Pugdog's remarks are representative of most Links users situation - at least the one's that have tried to password protect their Links page(s). Personally, we've probably spent as much time searching out and trying different password protection schemes (with NO success) as we have setting up the whole rest of the Links page. This truely sucks!

If it wasn't for the fact that GTI's Links is the (otherwise) best links program on the web, we would have erased it long ago out of frustration.

So, my point is this: while implementing your own particular customized password protection scheme, in Links, may seemingly be rewarding, it's a major irritation and inconvenience for many/most webmasters, and delusional in its effect.

I don't care what YOU do for your server-side protection scheme - someone will be able to hack into it. So, why not at least include a little protection code in the product, straight from GTI? I think the customers would be better served by this line of action, and would put Links back in step with every other links product on the web, in this respect.

As stated, Links is already the best links program on the web. Why not give the customers what they want instead of steadfastly fixating on your quest to force them into falling inline with YOUR misguided beliefs that server-side password protection will solve the problem?




------------------
Lenon.com Homepage
www.lenon.com
------------------
Lenon.com Links Page
See our "Snap Interfaced"
Gossamer Threads Links v.2.0
www.lenon.com/links/pages
------------------










[This message has been edited by Snap Head (edited June 28, 1999).]
Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
Not supplying password protection was a consious decision, not a missing feautre. If I added a username/password to the admin, it would fool the user into not doing the right thing and using server side protection to protect the entire admin directory.

Contrary to what you think, server side protection is the right thing to do!

Quote:
I don't care what YOU do for your server-side protection scheme - someone will be able to hack into it.

If I was installing a script, I would trust my web servers password protection a lot more then any CGI script. I've seen enough holes in CGI scripts to know which is more reliable.

Quote:
Why should we have to do all this work to password protect GTI's Links program?

You have several options:

1. Hire an installer.
2. Use a better ISP. Lot's of ISP have nice web front ends for you to type in a username/password and a directory and it will password protect it for you. Done in two seconds. If your ISP doesn't have it? Ask them for it or move to someone who does. Eventually they'll learn.

Quote:
If it wasn't for the fact that GTI's Links is the (otherwise) best links program on the web, we would have erased it long ago out of frustration.

Was password protection really that much frustration, or was it the whole install process? With installers listed at under $25, perhaps consider one of them? Also, you should be able to turn to your ISP as a resource.

I'd be interested to hear why you think server side protection is not the way to go? Is it purely because of difficulty?

Cheers,

Alex

Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
I'm just wondering why you want to password protect links if...

Quote:
Because security on the web is largely an illusion. This would include server-side protection
schemes. The fact is, the more protection you THINK you have - the less protection you
probably ACTUALLY have.

htaccess, with good passwords, changed often (something that I should do myself Frown )
will keep out 99% of the people on the web. The rest probably will find a way if they want to.
You were able to get the password out of the UBB (Ted really should encrypt them.), so why
wouldn't someone be able to get the password from links?

------------------
JRM Studios www.jrmstudios.com
The Hotrodding Network www.hotrodding.net
Web discuss Free speech newsgroups - www.webdiscuss.com



Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
Ok, now I'm confused. You use UBB as an example, but UBB uses CGI based security, and we just saw the results of that. I would much prefer if all the data could be thrown in a single directory that you could either move out of the document tree, or protect with server authentication.

Cheers,

Alex
Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
Hi Alex,
Nice to "talk" to you again Smile I know we've had a similar conversation via e-mail, but I thought I would turn it into a Forum topic, for general consumption.

This is getting to be a rather long thread (no pun intended) so you might have missed a twist or two.

Quote:
I'd be interested to hear why you think server side protection is not the way to go? Is it purely because of difficulty?

The quick answer to that is: Because security on the web is largely an illusion. This would include server-side protection schemes. The fact is, the more protection you THINK you have - the less protection you probably ACTUALLY have.

You may have read, in one of my messages above, that I generally despise Madrona Park's UBB, but use and promote their Ultimate Guestbook product. One of the reasons I dislike UBB will become apparent to you shortly.

I posed the original topic as a question, "Do you want Password Protection in the next Links version?" I already knew what the answer(s) would be, because of our previous e-mail conversation. I just wanted to see how many people would carp and parrot the standard GTI apologia (defense of position). I was not dissapointed.

However, I was suprised that one respondent went further and proclaimed: 1) that people who ask for password protection are ignorant, and 2) I might as well get a UNIX server.

So, in order to point out the fallacy of this server-side hyperbole, I sniffed out his password in your UBB data files, and edited his Forum post. Then I went to his web site, hacked into his banner rotation CGI and setup an account for myself and flagged it to expire after a million hits.

I knew it wouldn't do any good to say, "Anyone can bypass UNIX server-side protection." The web is full of such boastful claims. So, I provided a benign demonstration of proof.

Luckily, he was a very good hearted person, and didn't mind my tom-foolery. As a matter of fact, he thought it was "a great joke". I hope you are of the same mind, Alex. As I told him, I wasn't trying to be malicious. I was just trying to prove a point.

So, anyway, the long-n-short of it is this. Just because a user doesn't want to hassle with password protecting his WinNT web server and/or your program, don't assume it's because he's ignorant or it's "purely because of difficulty. And if he goes to the trouble of doing server-side protection, don't mislead him into thinking this is the ultimate solution. Speaking of 'ultimate solutions', now you know one of the reasons I dislike UBB Smile

If you don't mind me beating a dead horse...

Quote:
I don't care what YOU do for your server-side protection scheme - someone will be able to hack into it.

Hey, this is turning into a real diatribe, eh what? Smile

Well, that's my reasoning, Alex. Make any sense now?

Cheers!

------------------
Lenon.com Homepage
www.lenon.com
------------------
Lenon.com Links Page
See our "Snap Interfaced"
Gossamer Threads Links v.2.0
www.lenon.com/links/pages
------------------








Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
Now we're getting somewhere. The wall of dogma surrounding this issue is beginning to crumble - YES! Smile

Quote:
I'm just wondering why you want to password protect links...

Quote:
Ok, now I'm confused. You use UBB as an example, but UBB uses CGI based security...

Let's attack it from this angle, guys:

1) Thinking any web site is protected and secure is self-delusional.

2) Having said that, ANY protection is better than NO protection.

3) Links has no built-in protection(s).

4) Worse, Links has an administration page that enables and facilitates unauthorized intrusion(s).

5) Users have asked for (CGI based) protection, but are ignored, placated or attacked depending on the respondent.

6) For most users, password protecting the admin.cgi is all they need (and want).

As for your confusion, Alex; this is probably my fault. I didn't explain myself clearly. I don't like UBB for a multitude of reasons, the biggest being it's user registration requirement, not it's use of CGI based security.

In the case of UBB, visitors can view the topics and responses, but users must register to interact. Then, UBB generates a password which is sent to the user via e-mail. So, from a user standpoint, security has already been breached and anonymity destroyed. The webmaster, and god-only-knows how many moderators, hackers, et cetera, now have access to your name, nickname, e-mail address, password and so forth and so on.

Further, as stated before, people are lazy and will most likely pref-n-prof their password to something easier to remember. As unbelievable as it may seem, they will often use the same password as they use elsewhere, even the one(s) they use to administer their web site. So, now you have security breech number 2, and I might say, the death knell.

As a sysop and (now) webmaster of 13-years, I would ask you this, Alex. Given the above (and common) UBB senario: How many users sites could YOU 'hack' into, merely using the registration information that is contained in your UBB data files, regardless of the server-side protection employeed? Smile

I hope this clears up some confusion for you. There are many ways to breech and/or bypass even the most stringent security measures. I recently read a 'trade magazine' that devoted an entire issue to the 100 favorite methods that hackers use to gain access to corporate and goverment computers via the internet. It was exquisite and accurate in every detail. I'm sure plenty-a-hacker will find it invaluable in their misguided endeavors Frown

So, the point of this message is:

1) While server-side security is generally superior to CGI based security, it is in itself NOT a cure-all.

2) Webmasters (myself included) want and expect some sort of script protection in any CGI program that they may use.

3) Most, if not all, other links programs offer this feature as standard.

4) Including such protection would not send the wrong message (to users) any more than implying server-side protection will take care of all their security problems.

Well, let's run this message up the flagpole and see who salutes. Thanks, Alex, for listening. I hope my logic isn't confusing you even more Smile

------------------
Lenon.com Homepage
www.lenon.com
------------------
Lenon.com Links Page
See our "Snap Interfaced"
Gossamer Threads Links v.2.0
www.lenon.com/links/pages
------------------








Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
Hello!


Quote:
Well, let's run this message up the flagpole and see who salutes.

Well, well, I do...............

(I know that Alex will have a good laugh about it!)

------------------
rajani











Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
Hello Rajani,
And, I salute you, sir. I've enjoyed reading your many posts in other threads. It's nice to have a few independent minds around, isn't it? Smile

------------------
Lenon.com Homepage
www.lenon.com
------------------
Lenon.com Links Page
See our "Snap Interfaced"
Gossamer Threads Links v.2.0
www.lenon.com/links/pages
------------------








Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
Wow, did this thread fizzle out, or what?

I guess that means no password protection in the near future, eh?

------------------
Lenon.com Homepage
www.lenon.com
------------------
Lenon.com Links Page
See our "Snap Interfaced"
Gossamer Threads Links v.2.0
www.lenon.com/links/pages
------------------








Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
You can do basically what you want to do with .htaccess files. Plus the passwords that they use are encrypted.
Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
.htaccess authentication is fine if you're running on a *NUX server. But, that doesn't help the poor WinNT/IIS webmaster.

As I've indicacted (and even demonstarted) in this thread, server-side security isn't a whole lot better than client-side password protection, in most cases. *NUX web servers are marginally better than WinNT/IIS servers in this respect, but before you try server-side protecting your Links files on a WinNT machine, be aware: SERVER-SIDE PASSWORD PROTECTION ON A WINNT/IIS WEB SERVER CAN BE EXTREMELY RISKY.

Just so there is no chance of ambiguity, let me say up front that I feel that the way that IIS has chosen to do HTTP authentication is very broken. OK, that's out of the way ...

In order to password protect documents using IIS, you have to actually create user accounts on the NT machine. You then assign permissions to the various documents so that those users have permission to read those documents.

While this sounds simple enough, keep in mind that this means that user accounts and passwords are being passed across the Internet in PLAIN TEXT. Of course, this is also the case with ordinary Basic Authentication, but with other HTTP servers, intercepting this name/password pair simply means that you can access those web pages, while with IIS it means that you can actually log into the NT machine running the HTTP server.

IIS also has an authentication scheme called "NT Challenge and Response", which uses some variety of encryption with the password. However, this is not supported by the Netscape browser, and is not part of the HTTP standard, so should not be used unless you are sure that all of your client browsers will be IE.

So, thanks for the suggestion, but I'd still prefer to see some sort of password protection built into the next version of Links, like every other Perl script we use.

------------------
Lenon.com Homepage
www.lenon.com
------------------
Lenon.com Links Page
See our "Snap Interfaced"
Gossamer Threads Links v.2.0
www.lenon.com/links/pages
------------------


[This message has been edited by Snap Head (edited July 14, 1999).]
Quote Reply
Re: Do you want Password Protection in the next Links version? In reply to
 
Quote:
As I've indicacted (and even demonstarted) in this thread, server-side security isn't any better than client-side password protection

First off, we are comparing server based authentication and script based authentication. I don't think you mean client-side (i.e. using Javascript). Secondly, your demonstration merely showed how script-protection and the lack of picking good passwords pose a security risk. I fail to see why it demonstrates that script-based is superior to server-based.

Quote:
While this sounds simple enough, keep in mind that this means that user accounts and passwords are being passed across the Internet in PLAIN TEXT.

So are telnet and ftp passwords. If you are concerned that much about it, make your admin only accessible via secure server (https).

Cheers,

Alex
> >