Re: Dialback authentication

On 12-09-12 04:36 PM, Evan Prodromou wrote:
> On 12-09-07 01:55 AM, Michiel de Jong wrote:
>> Cool stuff! some remarks -
>>
>> 1) The Date field seems to introduce a one-second granularity which
>> seems quite arbitrary. For instance, if a client is continuously
>> sending one request every 10ms with the same token, then this would
>> cause the server to have to check its validity once every 100
>> requests. Also the other way around, if a client sends a request every
>> 10s, then each request needs to trigger a check, even though maybe you
>> would want the token to have a validity of say 5 minutes.
> The "token" field makes it possible to send as many requests as you 
> want. You can only have one request with the same (host | webfinger, 
> endpoint URL, token, date) tuple.
>
> This makes the token carry the weight both for sub-second granularity 
> /and/ for sufficient randomness to provide brute-force attacks, but it 
> seems to work OK for OAuth, so I think it should be OK here. Since 
> it's of arbitrary size, you can fine-tune as needed.
I thought I'd share my implementation estimate here.

    B = bits per token

    P = acceptable probability of a brute-force hit
    R = rate of hits per second (both for calls and attacks!)
    W = window size in seconds

    G = number of guesses to attack one request before window closes

    G = R * W

    N = number of attackable values
    B = ceil(log 2 N) + ceil(log 2 R)

    N = G / P

    T = attack duration in seconds
    P = 1 / T * R

    T = lifetime of universe = 10^18 s ("one hit in the lifetime of the
    universe")
    R = C10K x 100 = 10^6 /s
    P = 1 * 10^-24

    W = 10 min = 600 s = ~10^3s
    G = 10^6 * 10^3 = 10^9

    N = 10^9/10^-24 = 10^33
    log 2 N ~= 34
    log 2 R ~= 7

    B ~= 42

I used this to convince myself that 64-bit tokens are probably fine, 
even if R goes up another few orders of magnitude.

-Evan