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

[Ryan Rawson]

To complete this discussion, the search space of phone numbers is
absurdly small.  Salt doesnt really work because it's visible, and
given that its trivial to get a computer to brute force 280m md5
hashes/second on a modest ATI graphics card (for more info, see my
5mof talk on bitcoin from last year) that nearly every machine has
now.

Bcrypt is designed to be computational expensive to compute.  Be
careful not to tune it up too much, since under load, with CPU
starvation, bcrypt times can take a long time.  ie: 200ms *4 is now
800ms, which is pretty user visible.  I'd stick with the load factor
of 10, or even go to 9.

As for Databases and indexes, B+trees are really efficient.  With a
standard block size of 4k, you can index a lot of with a 3 level tree,
and the first 2 levels can be 100% cachable in modest RAM, now you are
1 seek for any value in your database, which is 6ms on unloaded disks,
so therefore the speed of a warmed up system is bcrypt_time +
seek_time, which can easily be under 250ms.  Which is as close to
near-real-time as you'd need for a door system.

Given a smaller list, that is relatively static, we can do one better,
which would be an in-memory list of bcrypt hashes.  Use a sorted
array, can use copy-on-write for no-sync issues, and binary search is
really efficient (as efficient as algorithms come).  Can write a
webservice in scala for this in a few hours pretty ezpz. It would have
2 methods, one to add phone #s, and one to verify phone #s.

On Wed, Feb 8, 2012 at 9:24 PM, ryan rawson <ryanobjc at gmail.com> wrote:
> Salts don't work anymore.
>
> Sent from your iPhone
>
> On Feb 8, 2012, at 6:34 PM, John Adams <jna at retina.net> wrote:
>
> This is exactly the problem hashes were meant to solve. Just use a hash like
> md5 or, hash the numbers into strings and let the database sort it out.
>
> You'll also want to salt the hashes, or otherwise it will be trivial to
> write a script to decode all numbers with a simple rainbow table attack.
>
> Sent from my iPhone
>
> On Feb 8, 2012, at 18:29, girlgeek <girlgeek at wt.net> wrote:
>
> YES!  A list (database table with index) really should NOT take very long to
> search a couple of thousand records in real time if written correctly.
> (Don't start me about writing code correctly).
> -Claudia
> On 2/8/2012 3:40 PM, Shannon Lee wrote:
>
> If you have an index if bcrypt'd phone numbers, you can simply bcrypt the
> incoming number and search the index for that hash, yes?
>
> --S
>
> 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.
>>
>> -c.
>>
>> _______________________________________________
>> Noisebridge-discuss mailing list
>> Noisebridge-discuss at lists.noisebridge.net
>> https://www.noisebridge.net/mailman/listinfo/noisebridge-discuss
>
>
>
>
> --
> Shannon Lee
> (503) 539-3700
>
> "Any sufficiently analyzed magic is indistinguishable from science."
>
>
> _______________________________________________
> Noisebridge-discuss mailing list
> Noisebridge-discuss at lists.noisebridge.net
> https://www.noisebridge.net/mailman/listinfo/noisebridge-discuss
>
>
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1834 / Virus Database: 2112/4796 - Release Date: 02/08/12
>
>
> _______________________________________________
> Noisebridge-discuss mailing list
> Noisebridge-discuss at lists.noisebridge.net
> https://www.noisebridge.net/mailman/listinfo/noisebridge-discuss
>
> _______________________________________________
> Noisebridge-discuss mailing list
> Noisebridge-discuss at lists.noisebridge.net
> https://www.noisebridge.net/mailman/listinfo/noisebridge-discuss