Hi Amit Klein (+bugtraq)

> One thing that I think can perhaps be improved is the amount of
> persistent data (the seed values) that the system keeps (in memory?).

Too true - but please bear in mind that the example used to implement
resource metering was really just an example, and was based upon the
anti-spam "hashcash" model. This was purely done to keep things as
simple as possible and for those familiar with that implementation to
quickly see how it could be used in web-based auth.

The core of the paper revolves around the use of client-side
computationally intensive routines that are designed explicitly to cause
a delay in submission to the server. The general criteria for a
solution are:
a) It needs to be client-side.
b) It needs to be controllable - i.e. easy to increase/decrease the
processing requirements.
c) It must be quickly verfiable by the server.
d) It should be appropriate for the application it is helping to protect.

Outside of that, it's fair game - the implementation fine points are
down to the organisation that chooses to make use of an "electronic
payment" resource metering solution. ;-)

>
>It should be noted that with this modified scheme:
>a. A calculation done for one username+password pair is useless for
>another pair (perhaps with the same username), because both the
>username AND the password are part of the hashcash string.
>
I would not normally recommend the use of passwords in this manner.
Basically, a password mapped to a user/customer should not really be
stored anywhere at the server end - instead a hash of the password is
stored (therefore, should anyone gain access to the database - they do
not have the passwords). In practical terms, this means that when a
customer submits their auth details to the server, it calculates the
hash of the submitted password and compares it to the hash it has stored
in the backend database.

For your proposal, the server would need access to the real password to
verify the hashcash. Perhaps if the client-side sends a hashed value of
their password instead?

Cheers,

Gunter

[ reply ]