Spring 1998 - CS513 System Security - Programming Project 2 Grading Criteria

Programming Project 2: Grading Criteria

Below please find the grading scheme we used for phase I of the programming project.

Regrades. If you believe that the grading scheme was misapplied, then you may submit a hardcopy, written regrade request at room 4115 Upson prior to May 4. This request should include:

A typed explanation of why you think you received the wrong grade.
The annotated, graded material that we returned to you.

For such requests, we will review the entire project and the way that it was graded. Your grade may increase or decrease as a result of the increased scrutiny.

Specious regrade requests are strongly discouraged and will be dealt with harshly. If your regrade request does not have a credible basis, then we will assume that you understand even less about the project than your original grade indicates. And your grade will be reduced.

Course staff are prohibited from discussing grading or grades.

Possible Project Grades and What They Mean

E (Excellent): Implemented Lamport's scheme, storing m and n values at the server, decrementing n before sending and then hashing the client's reply m-n times (see last year's lecture notes for full presentation). This is a superior implementation because it limits the number of online, attacks which can be made, and does not introduce a potential security flaw when the server crashes and restarts (see below). An E also required use of salt and password checks.
VG (Very Good): Lamport's scheme without using only n, or an equivalent authentication scheme, as well as salt and password checks.
GF (Good Faith Attempt): A partial solution was submitted.
U (Unsatisfactory): The solution did not show understanding of the problem at hand or its solution.

Extra credit was awarded for logging client-server interactions, compatability with phase 1, for good documentation, and for general inventiveness in the design.

Decrementing n after a teller is authenticated introduces a potential security flaw on server restarts because the server could crash during authentication, after the client has sent h^n-1(passwd) already. Then when the server restarts, it will challenge the client with n-1 again! So a wily attacker could exploit this "feature" and capture h^n-1(passwd) to reuse it in the event of a crash.