Quote:
First off, we are comparing server based authentication and script based authentication. I don't think you mean client-side (i.e. using Javascript).
Well, yes and yes.
Yes, we are comparing server based authentication and script based authentication. Or rather, a lack of script based authentication in Links, relying solely on server based authentication for protection. But, I don't think I'm drifting too far from the core argument.
I understand the stance GTI has taken. And, I agree with it from a programmer's point-of-view. If I'm reading the situation correctly, you've shifted the responsibility of password protection, and hence liability, from GTI to the end-user, using the assumed technological superiority of server based authentication as the rationale.
However, if you'll remember, I framed my original question and comments in a "Windows cry baby" context
and that's where I was headed with the client-side comment. So....
Yes, I did mean client-side password protection or "client request containing credentials" as Microsoft puts it. I don't think we should get hung-up on precise terminology and definitions, but I'll try to be more accurate so as not to confuse.
Quote:
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.
I don't pride myself as being a hacker, but let's just say I easily went around both the server based authentication and script based authentication on two sites in less than a half-hour. Neither site or type of authentication was any harder to circumvent than the other. So. let's just leave it at that. The point was supposed to be, one is NOT superior to the other from a security point-of-view. Although, from certain other stand-points, such as product liability, I can understand the preferability of one over the other.
Quote:
If you are concerned that much about it, make your admin only accessible via secure server (https).
Well, this was a little patronizing on your part, but I suppose I deserve it at this point
I know I'm belaboring this discussion. I'll give up soon...
First of all, you can't Telnet into a WinNT/IIS server. At least, not to my knowledge. However, you can FTP into one. Actually, there are three ways to get into a WinNT/IIS server via the net:
1) An FTP client logs on with a valid Windows NT username and password.
2) A WWW (HTTP) request's headers contain a username and password.
3) A WWW browser supports NTLM (Windows NT native) authentication, and an anonymous client request is denied access to a resource.
In the first two instances, you're sending your name/password across the Net in clear text. In the last instance, you're sending your name/password encrypted NTLM protocol which you can only do with I.E.
Yes, I could setup Links administration in a secure link, but then I still have to add the password protection code to YOUR program, which takes us back to the original argument.
What I was trying to point out in the previous message was that nobody is going to use NTLM authentication on a WinNT/IIS web server because it's browser dependent. So that leaves us with HTTP basic authentication which is easy to "sniff". And once someone intercepts this information, they'll be able log onto your WinNT/IIS server at an administrator level.
If there was at least SOME script based authentication in Links, it would make running it on a WinNT/IIS server much easier and safer, albeit less secure than if we took the huge risk of running in a basic authentication mode.
Since we seem to be getting into a circular agrument here, let me ask you this. Can you explain to me how NO password protection in Links is superior to ANY password protection? That is, how can no password protection be better than some?
[This message has been edited by Snap Head (edited September 23, 1999).]
