Worth implementing 'passwordless' user accounts for survey app?

Hi folks,

I’m currently making a survey/questionnaire application with Meteor. Before the start of the survey, the participant is asked for their name and email address. I currently simply save the name and email address as part of the survey answers.

For the moderators of the survey, I am using accounts-password for authentication. Only moderator accounts then get to see the survey results.

My question is: would it be useful it to create a ‘passwordless’ account system for the survey participants? It certainly is more uniform (all accounts are managed by the same package). Is it also more secure? As in, names and email are stored more securely?

In any case, participants of the survey are never asked for password and these are not stored. Which is why initially I did not lean towards create ‘passwordless’ accounts for them. What are the pro’s and con’s? What do you guys recommend?

Thanks in advance!

A system that doesn’t provide authorization is not an account system.
If you use HTTPS the data you transfer is MITM-protected.
Names and email are not stored “more securely”.

I think if you meant something more complex than just storing emails, please, explain your thoughts better.
If not you may store their email and name and token if you need right inside the same documents as survey.

1 Like

Tracking a user based on authentication gives you an account system. If there is no authentication, you might simply call it “tracking a user”. A good rule of thumb here is to assume the highest possible breach of information is reached. Ask this question: “If we assume everyone can see everyone else’s content, would everyone be comfortable with that?” If the answer is “yes”, then there should be no problems keeping the information unprotected.

One Solution:

What you could do is use obfuscation and associate a unique link to a user when they complete a survey. This is used by websites like Github to implement secret gists. Note that obfuscation should not be confused with security. Having a “passwordless” user tracking system allows everyone to see everyone else’s information.

Each user would get a link like this upon completing a survey: https://yourdomain.com/surveys/<secret token>

Then, a user would be texted (twilio) or emailed (mailgun, etc.) their secret link upon completion to take a new survey from that link. If they use this link from now on, the surveys completed with this link will all get stored as “that user’s” surveys.

Thank you for the replies.

You are correct. I do not authorize the user, I merely track their name so the moderators can see who’s who, and track email address to send them a post-survey email.

Thank you for the rule of thumb. The highest breach would mean that participants and their survey answers are disclosed. However, I need some way to tie the survey results to the user. If I were to add proper user accounts (say, with passwords) for participants, I would still need to tie user accounts to personal survey results. A highest level breach would thus have the same problem, no?

I understand that security through obscurity is not to be confused with security. However, since participants do not need to complete a second survey, we do not need secret links or anything like that. A simple post-survey email is all.

I mean, we assume the user accounts system is fully secure, and that no user can access another user’s information, but you’re right. to be picky, all you need to do is brute force the user/pass and then you can, lol, and it is possible.

If you only need to send a post-email, then all you have to do is ask the user to enter their email and then run an email sender on your backend, so I am not sure what the issue is there. My thinking is: why would you need a “password-less account system” aka a “Tracking system” if you only interact with the user once? Makes no sense, unless I’m missing part of your setup.

As to your first point: I do not mean to be pedantic. I am sorry if I have come across that way.
What I meant was: the moderators do have access to the participants information (name, email, and survey results). That means the database cannot be set up in a way that only the participant can access his or her own data. That spawns my concern that with or without participant authentication the same problem occurs.

As to your second point: indeed, I do not need an elaborate tracking system. I only need to tie the three elements (name, email address, survey data) together, in order to send the email. My original question thus not only had to do with security, but also with Meteor application design (are there pro’s to creating ‘accounts’ for participants, or should I simply store the name and email address along the survey results)

You are the god of this system. It’s up to you to give moderators access to certain content. All you do is query the right content for them. Why can you not do this? For example, if current user is a moderator, return all user’s information. etc.

Creating accounts for this would be tragic overkill. All you need to do is include a name and email field in your survey which they enter upon submitting the survey. Then, you are the master of the information on the server and can do whatever you want (send the email).

Thank you for the quick reply. I agree, that seems easy enough. I also agree that creating accounts seems like overkill. That is why I initially decided against it, but I value the community’s thoughts on this.

Simply storing name and email alongside survey data on the server seems like the straightforward way to do this. However, I still have trouble reconciling that with your rule of thumb: if a breach of the highest level occurred, then all of the data identifying participants along with their survey data is out in the open. Or am I still misunderstanding something?

Actually, not really, unless you provide a search in your DB. My assumption was that you were trying to display these filled out surveys on your website. It appears all you need to do is get answers for the survey questions, and then store the survey.

I am still confused why you do not do the obvious thing:

const survey = {
  email: "abc@xyz.com',
  name: "Abc X. Yz",
  questions: [
    {q: "What is your cat's name?", a: "Pookie"},