ACCC Home Page ACADEMIC COMPUTING and COMMUNICATIONS CENTER
Accounts / Passwords Email Labs / Classrooms Telecom Network Security Software Computing and Network Services Education / Teaching Getting Help
 
The ADN Connection, April/May/June 1998 The A3C Connection
April/May/June '98 Contents A Time of Opportunity, a Time to Move On (from CMS) Keeping Secure on the Web Web Security for Files and Data The ADN Post ADN Free Summer Seminars Cookies on the Web
Picking Keywords for UIC Search Copyright and Fair Use Operating Systems Support Group Guidelines on Email Size Active Content on the Web About the ADN Connection  

Web Security for Files and Data

 
News and Reviews WWW Everyone 
The Web files you have on tigger and icarus (a.k.a. www.uic.edu and www2.uic.edu) are as safe from tampering as your regular files on those machines. Any vulnerability depends on the usual: you must set the proper file permissions and keep your password safe. We make nightly backups, so you'll be able to recover in case of disaster or if a malicious hacker gets past our overall security systems or if you just save a file that you're working on in the wrong place or with the wrong name.

The main difference between Web files and other types of files is that you almost always give them public read permission; without it, the Web server couldn't serve them. This implicitly gives local users -- on tigger and icarus -- read access as well. This is normally not a problem; you do want the public to see your Web files, after all. But be sure not to give public write permissions to either your files or directories!
 
   
 
     
Want to secure some of your Web files?
  The "Web Security and Restricted Access at UIC" Web page explains how: http://www.uic.edu/depts/accc/webpub/security/

If the material you want to secure is for a specific class, you might consider using a class conferencing system such as FirstClass or perhaps Mallard. They were introduced in the Oct/Nov/Dec '97 ADN Connection. For more information, contact the ITL by email at itl@uic.edu or by phone at (312)996-9824, or visit the ITL home page: http://www.uic.edu/depts/accc/itl/

Return to Contents

 
     
Restricting Access to Certain Web Files
  But what about documents you want to distribute on the Web but are intended to be viewed only by a restricted audience? Can do. In fact, there are several ways. But first, you'll need to understand two terms:
  • Authentication -- Verification of who you are.
  • Authorization -- Given that the server knows who you are, the decision whether to grant access.
Most restricted-access schemes handle authentication and authorization separately. A big advantage of this approach is that a single authentication scheme (Bluestem for example; see Password Restrictions below) can be used for a variety of applications, even when the authorization decisions are idiosyncratic. To the end user, at least, this makes accessing these secured systems appear more uniform.

In general, the user authenticates him- or herself, sometimes just as a member of a group (e.g. "on campus") or other times as an individual and then the server can make an authorization decision any way it wants to.

Return to Contents

IP Restrictions

Every machine on campus has a network address called an IP (Internet Protocol) address, and an associated name, often called the Internet domain or DNS (Domain Name Server) name. The IP address of every machine on the UIC campus starts with either 128.248. or 131.193. Furthermore, the DNS names of all machines on the UIC campus end in uic.edu. For example, the domain name www.uic.edu now corresponds to the IP address 128.248.100.51.

Sometimes it's enough to restrict access to anyone using a machine on campus (including the dialup lines); you might not care exactly who the person is. And since everyone on campus is welcome to view your files, you don't care about encryption over the ADN network. Restricting your files to machines that meet IP or DNS name requirements handles this case nicely.

Note, that IP addresses can change, and DNS names can change, too, although much more rarely. However, restrictions based on the uic.edu domain name and these IP addresses will hold for UIC for the foreseeable future.

Return to Contents

Password Restrictions -- Bluestem

Sometimes it's necessary to ask the end user for a password, just so you can let some users in and block others. Most Web servers offer a variation of what's known as basic authentication:
  1. The end user enters a URL or clicks on a link. The browser contacts the appropriate server.
  2. The server responds with "This file is restricted to the xxx realm."
  3. The browser pops up a small window, asking the user for an ID and password relevant to the xxx realm.
  4. The user types their ID and password and the browser repeats the request, sending the ID and password along.
  5. The server verifies the ID and password, checks its authorization list, and if it checks out, sends back the file.
  6. Meanwhile, the browser caches the ID and password, so next time this realm is accessed, the user doesn't need to enter their ID and password again.
Basic Auth has several significant drawbacks:
  • The ID and password are usually sent in the clear. (They are encrypted if the transaction takes place over an SSL link, but SSL is not required for basic auth.)
  • The ID and password are not related to any other ID and password the user might have, so they're hard to remember and often also hard to change.
  • The ID/password tables are often not stored securely on the server.
Wouldn't it be nice if someone would invent a method that would:
  • Use the same ID and password as your existing computer accounts.
  • Keep the ID and password secure, not revealing the password to programmers writing CGI applications.
  • Force the encryption of anything worth protecting.
  • Make it clear to the user when it was safe to type in a password.
Well, someone has. Ed Kubaitis, from UIUC, developed the Bluestem protocol to do exactly this. Bluestem, and the kerberos system that inspired it, is explained in a bit more detail in the March/April 1997 issue of ADN Connection.

Very briefly, here's how the access to a Bluestem-secured application looks to the end user:

  1. The user enters a URL or clicks on a link to the application; their browser sends the request to the server indicated in the URL.
  2. Since the user hasn't presented credentials yet, the browser's request for service is automatically redirected to the Bluestem ID server. At UIC, this is ness.uic.edu.
  3. The Bluestem server -- ness -- sends a request back to the user for their netid and then for their password. (This is done in two steps because, if the application allows, you can use a UIUC password when you contact a UIC application.)
  4. After successful password verification, the browser is automatically redirected back to the application, with credentials. The credentials include the user's netid, but not their password.
  5. Based on the netid, which the Bluestem server has authenticated, the server decides whether to give the user access to the requested application.
  6. All interactions between the Bluestem server and the end user and between the Bluestem server and the application's server use SSL, so the password and credentials travel over the network in encrypted form.
In particular, this means that you, as a member of the UIC community, can use your normal ADN netid and tigger/icarus/CMS password to access any Bluestem-enabled application at UIC, secure in the knowledge that you haven't exposed your password to any bad guys.

Return to Contents

 
     
Security in Transmission: SSL
  Most Web files are transmitted over the network "in the clear" -- which means that anyone eavesdropping on network traffic anywhere along the way between the Web server and the browser that requested it could intercept it. This is not a problem for public documents, but some documents on the Web are intended for a restricted audience; it wouldn't do if these documents were intercepted and read this way.

The standard way to combat this is to encrypt the document, and the most standard type of encryption on the Web is SSL, Secure Sockets Layer. One of the reasons it's popular is that you don't have to change the document, you just use a SSL-enabled server and browser to encrypt on the fly. URLs that involve transmission via SSL start with https: as opposed to the more usual http:. UIC runs SSL-enabled servers on tigger and icarus, if you should need them.

SSL does two things:

  • It encrypts transmissions to prevent eavesdropping (a.k.a. "sniffing"). This works in both directions, so the client can send sensitive information (such as passwords or credit card numbers) to the server, as well.
  • It displays a server certificate, signed by a "trusted third party." This gives the client assurance that he is connected to the proper server, and should prevent (or reduce) impersonation of servers by other rogue servers.
    •  Note that SSL does not protect the files while they reside on the server. Nor does it protect the files once they're downloaded. It only protects files during transmission. (Similar considerations apply to any sensitive data sent from browser to server.)
     
     
    Never go shopping on the Web without SSL protection for at least your credit card information! The URL of SSL-secured transactions begins with https: (rather than http:), and you'll see an unbroken key (Netscape) or locked lock (Internet Explorer) in a bottom corner of your browser.

    Return Contents

    		 
         
    Want to know more?
      The first stop is the "Web Security and Restricted Access at UIC" Web page: http://www.uic.edu/depts/accc/webpub/security/
    Also, there were articles in the March/April 1997 ADN Connection discussing encryption techniques in general and SSL and Bluestem in particular. Comments are welcome; please send them to
    Bob Goldstein, in his guise as www@uic.edu
    Illustration (c) SoftKey International Inc. and its licensors.
    		  
     

    The ADN Connection, April/May/June 1998 Previous: Keeping Secure on the Web Next: The ADN Post

    2000-1-20  connect@uic.edu
    UIC Home Page Search UIC Pages Contact UIC