Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] password protected directory Re:

From: joel::neely::fedex::com at: 16-Sep-2000 10:10

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- [jackseay--earthlink--net] 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-