Message-ID: <CAJm83bAx7GA=9oSLbhrc68U6ydeJ+FZcgK7m6K09fst7XGnG6Q@mail.gmail.com>
Date: Tue, 19 Feb 2013 21:20:26 -0500
From: Daniel Franke <dfoxfranke@...il.com>
To: discussions@...sword-hashing.net
Subject: A rubric for choosing cost parameters

>From the perspective of the administrator of a online service which is
required to keep up with a queue of incoming authentication requests,
the selection of cost parameters in a password-hashing scheme can be
considered as a trade-off between the following five factors:

1. m: the amount of memory that may be allocated toward the
password-hashing scheme. (smaller is better)

2. r: the number of authentication requests that can be processed per
unit time. (larger is better)

3-4. (l,\epsilon): except with probability \epsilon, the latency in
processing a given request does not exceed l. (smaller is better)

5. c: the security level of the scheme, in terms of the expected
monetary cost to the attacker of cracking a password within some fixed
time period. (larger is better)

Assume that the number of incoming requests during a unit time
interval follows a Poisson distribution with \lambda=r.

I think an appropriate way to guide the user through selecting
appropriate cost parameters is to allow the user to supply
worst-acceptable values for four of these five factors, and then
recommend cost parameters that optimize the fifth factor within
those constraints.

This suggestion, obviously, has in mind sophisticated users doing
capacity-planning for large-scale applications. For grandma's blog,
the Right Thing is to just automatically pick something reasonable and
get on with it.

Powered by blists - more mailing lists