Hacker News Reader

Comment by rybosome | Hacker News Reader

The article states that Google has deployed defenses against brute forcing, so attempting to do slow at a rate that doesn't trip these defenses may not be worthwhile.

I must admit that I don't understand how the number of characters corresponds to bits of entropy. Know of a resource that explains this?

View on HN

Napkin math incoming... Say you only used a-z in your token, at 1 character long you have 26^1 combinations, at 6 you have 26^6 or 308,915,776 combinations, which could easily be scanned. Increase the length to 26^ or 95,428,956,661,682,180, a big ass number, if we reserve 1,000,000,000,000 for actual items and create them over this range then the odds of guessing a correct token is 0.000000010479, then ban all the hosts which trip more than the average number of 404s.

> I must admit that I don't understand how the number of characters corresponds to bits of entropy. Know of a resource that explains this?

There are 26 letters; mixed-case doubles that for 52 choices; digits add 10 for a total of 62 possible choices for each character. That means that 2 characters have 62^2 possible configurations, 3 62^3 and so forth. If you take the resulting number and calculate the ceiling of its logarithm in base 2, you get the number of bits needed to represent it:

    (ceiling (log (expt 62 11) 2)) → 66 -0.5038376

    log(num_options)/log(2)

So for a 8 character digits-only value, num_options is 10^8, so log(power(10, 8))/log(2) = 30 bits. This means both 30 bits needed to store the value and 30 bits of security. It also works for octal or hexadecimal: just replace log(2) with log(n), like log(16) for hexadecimal.

You have your arguments swapped. 30 bits for 8^10, 26.6 for 10^8.

https://www.google.co.uk/search?q=log2(10%5E8)

Reply on news.ycombinator.com