Short answer:
Use the standard authentication tools in your web server, unless
there's some overriding concern they don't address (or you just
want to play around with hairy crypto code for the fun of it).
Long-winded answer below. ;-)
-jn-
[EMAIL PROTECTED] wrote:
>
> Is there a Rebol script to password protect a directory and/or
> file(s) on a server?
>
Why reinvent the wheel? User authentication is built into Apache
(free) and Netscape's web server ($). Once you tell the server
that a specific resource requires authentication (and set up the
group/user/password info) the server automatically requires entry
of userID and password for any access to that resource.
Having said that, if you're REALLY paranoid about packet sniffing,
you should be aware that the basic authentication scheme sends
uID/pw responses in base64, so it's trivial for someone who can
log your net traffic to crack.
>
> Would the same script work on different servers?
> Would other files be needed?
> Would the password and user names file be plain text?
> What would need to be done to configure it?
> What HTML would include or call it?
>
If you DO decide you need to roll your own, the answer to all
of the above would be, "It depends on how you want it to work
and how it's written." In general, however, you'll own the
entire server-side problem of how to maintain ACLs (and how
to keep them secure from server-side attacks).
If you want some other form of checking than the standard server
tools, you can either write your own custom client or use CGI.
If you write your own client, you own the entire problem of
managing the client-side user interface, client/server protocols
and interaction, and server-side processing. A non-trivial bit
of work, to say the least.
If you want to use a standard browser, then writing CGI scripts
that require initial identification before serving back HTML
content might be feasible (as in the following paragraph).
A quick glance at the script you cited (VERY quick) leaves me with
the impression that it's intended for a generic client/server usage
scenario, not for HTTP specifically. That script appears to assume
that the uID/pw data are available when auth-server is called, so
you'd have to write your own wrapper around it to get that information
ready and invoke auth-server at the right time, to get a yes/no
answer to whether the user is authenticated. You'd also have to
get the auth-client code to run (on client or server h/W) with
data obtained from the user.
In short, it looks like an interesting component part, but not a
complete out-of-the-box solution.
Off the top of my head, it appears that the quickest way to adapt
it for web use would be to have an HTML form filled out by the user
with uID/pw and run the authentication via CGI.
If you don't include some tricks in your web page (such as encrypting
the user entries with a JavaScript routine in the page itself) then
you're back to the same sniffing vulnerability as the built-in scheme.
In this case, why not just use the basic authentication?
If you DO encrypt the data with JavaScript prior to sending it, you'll
be broadcasting the JS encryption routine along with the page. If
your threat model includes attackers who'd look at the code and try to
figure out the inverse of your JS encryption routine, you'd need a
good one-way (very hard to invert) function, and those are VERY non-
trivial to design.
Good luck; hope this helps!
-jn-
