<<< Date Index >>>     <<< Thread Index >>>

Re: New Whitepaper: Anti Brute Force Resource Metering



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