[Noisebridge-discuss] Access control & Safety, both personal and general space.

[Jonathan Lassoff]

On Wed, Feb 8, 2012 at 3:38 PM, Casey Callendrello <c1 at caseyc.net> wrote:
> On 2/8/2012 1:39 PM, Jonathan Lassoff wrote:
>> Perhaps bcrypt the phone number and store that instead? That way, you
>> can verify that something's in there, but it can't be easily figured
>> out what it is.
>
> I'd thought about that. However, when a user dials in, we don't know
> their username, so we have to just test their
> "password" (the phone number) against every known entry. If the number
> of bcrypt rounds is too high, then it takes forever. Is there a hashing
> function I should choose that is efficient but will make just
> enumerating all passwords too slow? There are about 2360000000 possible
> north-american phone numbers based on currently-allocated area codes.
>
> I suppose bcrypt will be fine provided that all possible numbers can be
> quickly scanned.

Very good point. The password is the username in the caller ID case.
An alternative would be to have the user key in a number, but I think
that detracts from the ease of use for not a lot of gain.

bcrypt is tunable, so by tuning the cost accordingly, we could make it
fast enough to search our whole database (which isn't going to be
*that* big in the scheme of things) while still being hard to brute
force.

Chers,
jof