|
|
|
|
||
        |
|
 |
||||||||||||||||||||||||||||||
 |
 |
||||||||||||||||||||||||||||||
|
Security in Lasso In this column I will elaborate on the methods that I have used to help to secure the Online Testing Site that I developed. Just a general note that as with all sites my strategies are not full proof and were never intended to be. The major goal I set out was to secure the site to a sufficient level that satisfied my most critical users and to continue to be open to implementing new security ideas.
The Failures First let me elaborate a little on one of the methods I abandoned on my search for a successful security solution. As most active web-surfers know, cookies are a feature available in both major browsers and widely used by a number of sites. Cookies offer the ability to store small pieces of information on the client's computer that I can use to identify them in the future. This sounds like a perfect fit for tracking a user through your site and delivering dynamic content geared toward them. It does offer the advantage of insuring the user has access to the site and cookies also have an expiration feature. This way a session can time out and force authetication some predetermined time later. Unfortunately even with all the benefits of cookies, they have one major flaw. They rely on the web sufer visiting your site to accept the cookie (and/or to not have them turned off completely). In the short time that I used them this problem was the case with over 25% of visiting users. That was enough to make me look in other directions.
The Current Method of Protection In my online testing system the first security mechanism is a very simple
one. I only allow a user to see and access the portions of the site they
need to. In the student
case this is simply the tests they can take, and the grades on the
tests they have taken. In the case of the faculty,
it is a much wider palette including creating, editing tests, and managing
the grading of tests for their students. The third case is for the administrator
which includes an overview of all the faculty and students accounts and
the ability to change or add new ones at will.
I wanted to have the ability to track users without requiring them to authenticate themselves on every page. I essentially wanted the benefits of cookies without requiring the user to "buy-in" to the security system. The compromise was a user token that is set when the user logs in. This semi-random number (it is semi-random because part of it is based on Time/Date and part of it is completely random) is what the system uses to verify a user. This user token as it is called is also stored in the user database. It can be reset at any time but it isn't changed with each individual session. This token is passed from page to page either through the URL or in a post operation for a form that is submitted. The token is verified with the value in the database on each and every page. In addition to the user token, my system also uses a setup of password protected cache files which speed access to test data for students. The writing of these cache files and the access for students is restricted to only those who are authenticated by the system. The faculty have the ability to create new cache files with each test that is created. And the last major security feature of the system is that every user has their own database privileges. Students are restricted to searching and retrieving data whereas Faculty have some additional creating and editing privileges. The Admins are the only ones that have full access to all of the databases.
The Future The newest version of Lasso supports session tokens. Many of the databases that cater to the corporate market also support this feature. Essentially this is a number just like the user token only the database or middleware keeps track of it for you. The advantage is that authentication only needs to happen once and then a session token is created. If the user has a valid session token from the previous form submission or link then the time necessary for authentication on each page can be saved. It isn't much but each little piece of time saved is a benefit. Secure Sockets layer encrypts all transmissions to and from the server. It offers an additional layer of both perceived and actual security. It makes it more difficult for anyone ease dropping on the transaction to get something of worth from it. Unfortunately it also adds additional overhead to each packet sent which costs both the user and the server time.
The Conclusion In the case of security there are numerous options that are available. Finding the right combination is the key to have a great security solution for your site. In my next column I will investigate a new database as I began my journey to create and setup my first database on Mac OS X. Your feedback/suggestions or questions are very welcome.
|
|||||||||||||||||||||||||||||||
|
 |
||||||||||||||||||||||||||||||
|
