Programming Project 2: Grading Criteria
Below please find the grading scheme we used for phase I of the programming project.
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:
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.
- A typed explanation of why you think you received the wrong grade.
- The annotated, graded material that we returned to you.
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.