Use HMAC-SHA256 instead of SHA256 for hashing phone numbers

[sietseringers]

This solves this issue identified by @confiks by using HMAC-SHA256 on phone numbers instead of SHA256, before storing them as Redis keys.

Note that this adds new configuration to the application so the deployment(s) will need to be updated.

[kamphuisem]

Just a thought; couldn't/shouldn't we include the token in the hash (instead of storing it as one of the values) and match on the set, so that even if the database and secret key are leaked, the extra randomness makes it more secure?

[sietseringers]

That would be possible, yes. But it would also mean that the application isn't able to distinguish anymore between nonexisting sessions, and an existing session for which the user entered a wrong token. In other words, entering the wrong code for an existing session will result in an error message saying the session doesn't exist, rendering much of the logic in case of wrong tokens in TokenManager.verify() dead code. I don't think we want to go that far.