Some notes following the Identity Management Europe event, 14 March 2019, Frankfurt.

  • Ever wondered which are the biggest risks that we face? According to the World Economic Forum, a massive data fraud/theft or a large scale cyber attack rank in Top 5 most likely global risks, while the large scale cyber attack has the 7th most devastating impact. Worrying, no?
  • The fraud triangle: pressure (motive) – rationalisation – opportunity
  • Need-to-know – has strictly limited use cases (it comes from the military). In real life, we want the information to flow – don’t kill the business. There is always a fine balance between over-entitlement (leading to security risk) and under-entitlement (business risk).
  • MFA with yubikeys is the Graal of authentication – superior to everything else.
  • NIH: Not invented here: the strong bias against ideas from the outside.
  • Build vs buy: the main advantage of ‘buy’ is the fact that it allows the customer to concentrate on their core business.
  • In the cloud infrastructure there is the concept of zero trust. Deny all by default. Never trust. Always verify. Never trust the client. Never trust the server. Never trust the network.
  • Friendly reminder that the cybercrime became a 1.5 trillion business

Some emerging technologies:

Finally, some notes on automation:

  • Robotic process automation can be used for automatic testing (auto-filling of forms)
  • DevOPS (combining responsibilities of DEV, Q&A and OPS) – only possible if a big chunk of the work is automated
  • Workflow: Code > Build > Test > Deploy > Monitor – all of this automated (maybe except for the coding part 🙂 )
  • Remediation using automation: service not responding: auto-restart; load spike: auto scale instances; service fail: redeploy a new instance
  • Use automatic monitoring tools to detect bugs before your users (Splunk)
Rainy Frankfurt

Don’t hash secrets

Written on 21 September 2014, 04:10pm

Tagged with: , , ,

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)

custom_hmac
hmac2

And this leads to the following problem:

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… 🙂

iStock_000020861023Small
Photo: istockphoto