Don’t hash secrets, HMAC them!
This is an old but incredibly useful article written by Ben Adida, currently director of engineering at Square, previously working at Mozilla.
The idea is that simply hashing + salting the secrets is not enough. You need to HMAC them (Hash-function Message Authentication Code). HMAC always uses a hashing function (like MD5, SHA1, etc), but this hashing function is not used to hash the secret alone.

If you know SHA1(secret || message), then you can compute SHA1(secret || message || ANYTHING)
You don’t need to know exactly how HMAC works, just like you don’t need to know exactly how SHA1 works. Under the hood, what’s approximately going on is two hashes, one after the other, with the secret combined after the first hash.
– Don’t hash secrets, HMAC them!

PHP has the hash_hmac function starting with the version 5.1.2. Interesting enough, CakePHP’s default authentication mechanism only uses hashing+salt, not HMAC. And MediaWiki uses something closer to HMAC.

But there’s a catch. If the secret is longer than the block size of the hash function, then HMAC will use the hash of the secret. See here and here (screenshots below)

And this leads to the following problem:

`plnlrtfpijpuhqylxbgqiiyipieyxvfsavzgxbbcfusqkozwpngsyejqlmjsytrmd` and `eBkXQTfuBqp'cTcar&g*` have the same PBKDF2-HMAC-SHA1 hash

— CodesInChaos (@CodesInChaos) January 11, 2014

Mathias Bynens elaborates this:

SHA-1 has a block size of 512 bits, which equals 64 bytes.

So in this case, if the supplied key takes up more than 64 bytes, then SHA1(key) is used as the key. More generally, for any chosen_password larger than 64 bytes, the following holds true (pseudo-code):

PBKDF2_HMAC_SHA1(chosen_password) == PBKDF2_HMAC_SHA1(HEX_TO_STRING(SHA1(chosen_password))

PBKDF2+HMAC hash collisions explained

Takeaway? Don’t hash secrets, HMAC them. But make sure that the length of the secret is not larger than the block size of the hashing algorithm.
On the same line, maybe using passwords longer than 64 bytes is not such a good idea… 🙂

Photo: istockphoto

As promised in the previous episode 🙂

Probability to have a duplicate (Y axis) by the number of stickers (X axis) – with an album size of 192 stickers:

The number of distinct stickers (Y axis) by the number of stickers (X axis) – with the album size of 192 stickers:

Made with JPGraph in a few minutes.

The previous post about Panini stickers got into some mathematical formulas. However, the 2 main conclusions were referring to the duplicates probability and distinct probability. That was the mathematical approach to the problem.
Below – the geeky one 🙂

1. Duplicates probability

In a Panini pack of 17 stickers (out of 192 possible stickers), there are 50% chances to have a duplicate.

The geeky way:
– generate a random array of ‘n’ integers in the range [1,192]
– calculate how many duplicates has the array
– repeat this a number of times to get a reliable view.

Results (PHP code at the end of the post):

Number of stickers - Probability of duplicate
10 - 20.47% 
11 - 25.8% 
12 - 31.2% 
13 - 37.13% 
14 - 40.6% 
15 - 45.47% 
16 - 47% 
17 - 53.4%
18 - 58.4% 
19 - 63.27% 
20 - 66.53% 
21 - 69.87% 
22 - 74.53% 
23 - 76.53% 
24 - 80.27% 
25 - 82.33% 
26 - 85.47% 
27 - 86.27% 
28 - 87.87% 
29 - 89.93% 
30 - 91.67% 
31 - 93.73% 
32 - 94.4% 
33 - 94.87% 
34 - 96.07% 
35 - 96.53% 
36 - 97.13% 
37 - 97.47% 
38 - 97.6% 
39 - 98% 
40 - 98.33% 

(more…)