2

This is kind of a weird question maybe, so let me explain a little background first that I hope is relevant.

I work as a Developer/Analyst for an organization that operates in a federated model with a central authority, except I'm part of one of the many federated entities. We use software (CRM, Business Analytics, etc) curated by the central authority, but they are really bad about being able to provide us the tools and resources we need for our own software development, such as API access.

I am developing an application where we need to track visitors and need to ensure that the visitors we track are de-duplicated during multiple visits and generally identified in some way. Most of them are customers who have information in our systems, while many of them do not.

My preferred solution would be for our customers to sign in upon visiting with the Username/Password they have via SSO, while all other users would be tracked in another way. Even better would be a provided membership card or something that they can simply scan to identify themselves.

As I can't do any of that, I am creating our own Shadow IT API to integrate with our customer data that we pull from our BI tool via a crude ETL process (again, no support from parent entity).

The approach I'm thinking of will be to let visitors find themselves via an email address (something they know that typically others will not), or via a customer id (something that only about 1% of them will actually even know).

I'm worried that it might be a breach of Personally Identifiable Information if I let people search by email address, and they input addresses that are not their own and can see names of people that are not them. I don't know what the odds are for that given the extremely niche use case, but it could happen.

Are there any other approaches I might be able to creatively utilize?

Cowman
  • 123
  • 3

1 Answers1

3

My preferred solution would be for our customers to sign in upon visiting with the Username/Password they have via SSO, while all other users would be tracked in another way. Even better would be a provided membership card or something that they can simply scan to identify themselves.

(...) I can't do any of that (...)

There are three factors you can use for authentication:

  • First factor: Something the user knows (password): you say you can't do this one. I will assume that this is not a technical limitation. I imagine you have the technology to have a secondary database to store credentials. And you can't do that because reasons beyond the scope of the question.

  • Second factor: Something the user has: you say the membership card is not viable, also because reasons. There are alternatives. You could use something the user has access to. Will come back to that.

  • Third factor: Something the user is: for example biometrics.


I'm worried that it might be a breach of Personally Identifiable Information if I let people search by email address, and they input addresses that are not their own and can see names of people that are not them.

Yes.

The user should not see the search results unless authentication can be done. You need a layer between the user and the search.

I don't know what the odds are for that given the extremely niche use case, but it could happen.

I remind you that humans behavior is irrational, not random.

My guess is that chances of people noticing that there is no real authentication are high (they did not have to use a password or show any credential).

Beyond people using this to get information about others, I would be worried about impersonation/identity theft.

If you cannot add a software layer between the people and the search, one way to deter people from searching who they are not is the third factor: something people is. For example, a deterrent would be having a photo of the person shows up in the system and have a staff member overlooking who can compare the photo to the actual person.

That is also a way to use the third factor without putting a camera to people's face and using fancy AI software. Which are hard (for the traditional face recognition) or virtually impossible to understand (if they use artificial neural network reinforcement learning, for example), could be cheated (these systems have false positives), could be percieved a privacy invasion (where does the data go? is it being stored? is it shared with third parties?).


About the second factor...

A cheap alternative to a membership card, is to use email.

I suggest this approach (tweak it as you see fit):

  1. The system asks the user for his email.
  2. The user types their email.
  3. The system searches the database for the email.
  4. The system sends an email message with a (random, unique, single use, time limited) code.
  5. The system asks the user for the code.
  6. The user gets the code from the email account, and types it in the system.
  7. If the code matches... If the email was found in step 3, the system grants access. The email exists in the system and the person proved they have access to the email. Otherwise, you can tell the person that the email is not in the database, and indicate what are the next step (is there some registration process?).

If the email can't be sent. The email the user did enter is not valid. Tell the user.

If the system is asking for the code, let the user: 1) request the code to be sent again (with some delay, let us not let people use this to spam others. You may add a captcha, not for checking if the user is human, but to slow them down and make it tedious to use this to spam). 2) abort the process and start over.

Keep in mind that with this approach the person never has to see the search results. The only way to get access as another person is to have access to the email of that other person. Either that person has the email compromised, or they granted this access.

Note: I'm not suggesting to tell people right away if the email was not found, because that could allow the user to figure out who is in the system by typing the emails of people they know. Also know that this could become an inconvenience for users (a single typo would be annoying). If you add text telling people to double check, people learn to ignore it.


By the way, if you can build the above system on top of what you have. I believe there should not be a technical limitation to implementing passwords. I will not cover how to store passwords here. Hint: you don't. You can research that if you are interested.

Theraot
  • 254
  • 1
  • 5
  • We have been considering the approach of modeling a completely separate authentication solution for our users in defiance of the central authority as a way to provide better service to our customers. I really like your email suggestion. My biggest concern is the user experience, since they are "signing in" via a kiosk... and I'll have to think about that more. – Cowman Feb 05 '20 at 06:57
  • @Cowman Well, the idea of the email could work with any other messaging solution, perhaps that opens some possibilities. Sending MSN to a cellphone is a common alternative. Perhaps [ux](https://ux.stackexchange.com/) can help. – Theraot Feb 05 '20 at 14:29