3

I'm working on a way to verify personal information for tax receipt generation on behalf of an NGO.

I need to verify the following information:

Full Name
Mailing Address
Phone Number
E-mail

People involved with the NGO also have a unique ID, but they may or may not know it.

How would I build a system that lets a person verify that our record is correct, but does not allow a random user to login and scrap for user info?

Since this information is not obtained online, I have no way to know if any of our record is correct. I don't have a solid way of letting an individual know what our existing record is. Just the other day I found a record with e-mail address of somebody@y.c which is not remotely valid (no y.c TLD exists).

One way I thought of was, using Phone Number, E-mail, or their unique ID, I use their input to provide 10 sets of personal information, generated via an algorithm based on a seed (to prevent reloading the page and getting different results), with one of them being their record (if it exists), and they pick the one that's most correct, and then they are prompted to provide any changes.

I would like a more industry standard of doing this, but I have no idea how to look.

  • Who are these people involved with the NGO? Are they employees and volunteers, or are they members of the public having supplied their personal information? Also, you say have a unique ID, but they may or may not know it, but should they be able to know it (e.g. have they been given that ID as part of a process but they'd simply have forgotten it)? – korrigan Mar 25 '18 at 2:33
  • They are donors. The donations are made irregularly. The IDs are given to them and majority of them do know it correctly, but it is not 100% accurate, and some of them do forget due to the irregularity of donation period. – Nelson Mar 25 '18 at 2:43
3

It's hard to prove a practice is industry standard, but I will present some scenarios I have come across.

Let's look at some of your constraints:

  • The users should be presented only with their own PII when using the system
  • Users should not be able to search for other users' PII
  • Users do not necessarily know or remember the ID (key) they have been assigned

Your scenario of 10 randomly permutted profile info doesn't look acceptable, especially if it reveals actual PII without authentication -- someone knowing the person will recognise it, for example, or they may validate a profile is real by cross-referencing against other leaked PII databases. It may well break data protection regulations.

It sounds like your organisation already provisioned users accounts to store their PII and keyed it with a globally unique ID. You will need to come up with an authentication system that will help your users to log in and access their provisioned information. This system should allow a variety of authentication scenarios since not all users will be able to use their assigned ID.

Log in using the globally unique ID

This is a common scenario with organisations, however not necessarily the easiest. Typically, before the user interacts for the first time with the online platform, the organisation will most probably have been in touch with them through other means.

If your organisation is in communication with the user through any means (e.g. email, or postal mail), it may be a good idea to proactively specify the globally unique ID, for example as a header, as this should help with the "forgetting the ID" problem. Knowing this information, the user should be able to request a temporary password being sent through the same channel to claim the provisioned account.

The claiming process may include verifying the PII.

Log in using an email or a telephone number

Now, supposing that the users don't know their assigned globally unique ID, they should however know their own email address or phone number.

If a user inputs their phone number or email, you can search and match that against the database. If there is a match (i.e. the offline data gathering and digital entry worked without error), then you may send a temporary password to that same email address or phone number (e.g. as a text). It should be a safe bet to assume that they are personally in control of the email or phone number they have just entered in the system. The user may then enter this temporary password and proceed to verify and claim their user account.

You should not acknowledge any of the email address or phone number exist or don't exist in your database, however, and instead simply state an action would been taken should the entry be valid.

Some more thoughts

Now I understand I talked about "claiming a user account". I accept it can be a barrier for some users to create or otherwise possess yet again another user account and remember yet again another password, especially for something they'd log onto at most once a year. You may gauge the difficulty of requiring they set up a personal password to claim the account, but in the long run this may be beneficial -- I think the claiming process is more cumbersome than "normal" user account management, not to mention less secure.

Please note you would perhaps have to also think about a user support procedure, and hence a phone or other verification procedure.

On "temporary" passwords: you should decide if they need to be limited in time or if they'd only be deactivated once used the first time (one-time passwords).

I have also seen a process using the name and postal address as a form of identification, and the password would be sent in a letter at this address. Now I'm a bit less comfortable with this one, as it would require a manual intervention on the NGO side to assess the validity of the request -- the known name and address may differ with the information specified in the password request, so an operator should manually check if they plausibly match (i.e. different formatting, accents, etc...). This is open to human error, so I'm not recommending it, unless you have the resources and manpower to ensure it.

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.