Date: 2023-02-24

Status

Superseded - we will still salt our hashes, but we will do so using a different method outlined in 003 - Do not use NEMS or MESH

Context

We have decided to store hashed NHS numbers rather than store them in plain text.

The range of NHS numbers is relatively small - it is 10 digit number of which only the first 9 digits have meaning - the final digit is a check digit. This means that even with a secure hash, it would be vulnerable to a dictionary attack as it is feasible to iterate through all 999,999,999 NHS numbers.

We need to decide on a way to ensure the hash is secure, despite the small range. We are limited by the limited amount of data in the database, none of which will be unique, and the fact the person whose data it is will not be present (so there is no “username”).

Decision

We will salt the hashes.

In our specific case, we will do this by:

1. Keeping a separate unique identifier for each care recipient within the HANS system
2. For each care recipient, we will store a salt in plain text, for each care recipient
3. For each subscription we create - we will “tag” it with the unique identifier so the salt can be retrieved again later

Consequences

When receiving messages, we will need to use the tag to pick out the salt in order to re-hash the NHS Number and match it to a record in our system.

As NEMS supports this there is no immediate issue, however we will be limited to using systems which allow for this identifier to be stored alongside subscriptions in the future (whether as a “tag” or otherwise).