Can name and date of birth be hashed somehow to generate a secure identifier?

Question

I'm working on a project which we intend to launch for developing countries, and, as a result, want to limit the amount of information needed for login and identification, while still maintaining individual privacy and security.

Speaking to the team, it became clear that passwords are a no-go, as users may end up accessing the service only when they have a third-party providing the opportunity to access the internet (once or twice a year even). Remembering passwords, using emails, or anything of the sort would not work in that scenario.

The whole thing is I need to store some data about each user, and I don't wanna have any idea whose data it is. It isn't especially sensitive data, but I'm trying to build something that preserves privacy as much as possible.

I'm therefore wondering how to identify users with information they know and do not need to put any extra effort into remembering.

As a result, we've narrowed usable information down to: Full Name and Date of Birth (even DoB can be a problem for some). Intuitively, it doesn't look like one could build something very secure with that data. One key flaw with name and DoB is that one can easily go through all combinations for "John Smith" with all possible dates of birth and find a matching hash.

Therefore, a rough solution we have in mind is to hash name and DoB and use as "username" (all happening in the background of course). Some additional measures would be to scramble the date of birth and add a salt to the hash.

The authentication would then happen via facial recognition. The idea is to encrypt a picture of the user with some combination of the name and DoB as well, so at least it isn't as easily accessible to the database admin.

A user would log in only with their name, DoB and picture, in a system that would first search through the hashes until it finds a match, then decrypt the corresponding picture and compare the two pictures to allow login or not.

In summary, the user credentials would be something like:

SHA256(NAME + SCRAMBLED_DOB + SALT) => AES(PICTURE_DATA, (NAME+SCRAMBLED_DOB))

The salt could also be added to the encryption of the picture, such that, at login:

1. All potential versions of the SCRAMBLED_DOB are tested with multiple salts until a hash contained in the database is found
2. That specific hash and sequence of digits from the DoB found from Step 1 are used to decrypt the image
3. Image is compared with the image submitted at login, which is then discarded

This process could get long, but depending on how long, it may be acceptable in the name of privacy.

So, essentially, what I'm wondering is:

1. Would SHA256(NAME + SCRAMBLED_DOB + SALT) be safe enough, given the requirements of the project?
2. Any suggestions for a better way to encrypt the picture?
3. Any suggestions for this system overall?

Thanks in advance!

Answer 1

If you don't trust the third-party providing the opportunity to access the internet at the login stage, you should not trust at any stage. They can save any data entered, including data related to facial recognition. Also they can store any data that you users receive from your server. The risk of such misuse is high, because such data cost money.

Brute-forcing of NAME + SCRAMBLED_DOB + SALT is trivial, because the number of births dates is very small. To represent all possible birth dates in the last 100 years only 15 bits are needed. If you have 1 000 000 people in your database, this would mean just 20 bit. This is 35 bits in total. This means, your database can be easily brute-forced. You can slow it down by using Argon2 or similar instead of SHA256. But it will be still too easy to brute-force. The reason is, that possible secrets are not random, they are very easy to guess.

In case somebody is interested in decrypting data of particular person, it is even more simple. Such decryption can be done immediately, without any brute-forcing.

Your words until a hash contained in the database is found mean that you are going to store hashes in your database. This makes brute-forcing even easier. An attacker doesn't even need to search through different births dates, through names. Instead, the attacker will just take hashes that you store and will just iterate them and will easily find what hashes to what encrypted data are used.

What should you care about? There are many points. Here are some:

1. Make sure that connection from user to your system is secure. If it is not secure, soon or later there will be people or companies, that misuse that and will collect data about your users. You will cheat users if your will not explain that to them. Also requesting some kinds of information via insecure channels can be a legal problem even in many developing countries.
2. Any measures like encrypting data in your database make little sense if communication channel is not secure.
3. Establish reliable authentication. Many people in developing countries have mobile phones. That's why besides passwords consider sending one-time password per SMS.

Answer 2

Start with a QR-code printed on a plastic chip, containing a 256 bit number. From the QR code, name and date of birth you calculate a hash code in such a way that the QR-code is identifiable. And that is the key.

To log in, the user needs the chip, name and date of birth. Without the chip it is unhackable. If your husband/wife/child steals the chip, game over. If you lose the chip and a hacker finds it, they can try to guess name and DoB, but since the QR code is identifiable, they are locked out quickly.

If you lose the chip either access is permanently lost, or something needs to be set up so the person can take their passport or other real world Id to a trusted party to get a new chip. With obvious risks.

I’m sure someone will rip holes into this :-(