openrightsgroup/Blocking-Middleware — pull request #1 by liamja (2013-12-29 14:49:27+00:00)
Title: Harden the API

Was looking through the spec and noticed that it specified using MD5.

[MD5 is considered broken](www.kb.cert.org/vuls/id/836068) and I propose that a stonger hashing algorithm be used for storing user passwords; in this case I elected to use PHPs [password_hash](http://php.net/manual/en/function.password-hash.php) function which currenty uses the [bcrypt](https://en.wikipedia.org/wiki/Bcrypt) algortihm along with [key stretching](https://en.wikipedia.org/wiki/Key_stretching). If we can change the spec to at least SHA256, that would be much better.

The same salt is used throughout the application, whereas it would be more effective to generate salts on a per-user or per-probe basis, for instace by using password_hash. This can be negated by using key stretching.

The use of [rand](http://uk3.php.net/manual/en/function.rand.php) is not cryptographically secure for use with creating HMACs. I would elect to use one of PHPs builtin HMAC functions for this, but for now I've replaced uses of rand with [openssl_random_pseudo_bytes](http://uk3.php.net/manual/en/function.openssl-random-pseudo-bytes.php). The way the HMAC is currently generated `$probeHMAC = md5(date('Y-m-d H:i:s') . rand());` is prone to brute-force attacks because of the small amount of entropy and is very predictable.

I understand this would mean chanigng the spec, but thought it would be useful to show some of the changes that would needed to be made to the code base.

Cheers!