5

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!

  • 2
    Hashing potentially sensitive, low entropy data or deriving an encryption key from it provides a malicious party a means of recovering that information. They can then link that information to whatever other information you store for that user's account. (Encrypted or plaintext) That other information can be even more sensitive, especially so if it can be tied to a person's identity. Usernames and passwords have the benefit of permitting (not guaranteeing) pseudonymity, allowing credentials to be changed if they're compromised, unlike DOB or biometrics, and may make targeted attacks harder. – Future Security Apr 14 at 1:00
  • Indeed. Thanks! – Yakko Majuri Apr 14 at 1:13
4

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.
| improve this answer | |
  • I don't assume the third-party is untrustworthy, by the way. Those would be people on the field certified by the platform. My point was only that one may not have access to the internet him/herself, so would be likely to forget username and password by the time they use the system the next time. But this is great explanation simply confirming my fears. Thanks a lot for that. Will mark as answered but would like to pick your mind a little more. I thought about SMS 2FA, but one could link that phone number to the person quite easily, no? Also, any other suggestions? – Yakko Majuri Apr 14 at 1:15
  • @YakkoMajuri: Yes, using SMS will identify users. If you want to prevent it, SMS is not good. The users should have unique user names. They should not be derived from their normal names, because it can be easily brute-forced. If users have smartphones, one option would be to install an app and generate a random ID which would identify this user. (loosing smartphone means loosing information about user name) For password you could use one-time password generator on a smartphone. It would be not needed to remember password at all. – mentallurg Apr 14 at 2:36
  • Got you. I'm thinking of going with username and password after all, with a separate feature for those unable to do so. Was just wondering if there was a way around it. Besides system-generated usernames (rather than user-chosen), what would you recommend regarding an ID for users that would be easy to remember? – Yakko Majuri Apr 14 at 2:40
  • @YakkoMajuri: Alternatively, give users something that contains password: a piece of paper, a piece of plastic, an NFC chip. Think of Kerckhoffs principle. No matter how complex the logic you implement, it does not give security. Security should be based on something that one knows or has. There is no magic way around. – mentallurg Apr 14 at 2:41
  • You're perfectly right on that. Final stupid question (I hope): what about hasing the username together with the password to form the ID, and the password separately with something well-established like bcrypt? – Yakko Majuri Apr 14 at 2:42
3

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 :-(

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.