THEMA: Your feedback: Plugins for LimeSurvey 2.05

We are very excited to hear about the new plans for the plugin API.
There are many ideas that come in mind, but we would like to make a comment on the proposed encryption of the results of a survey (by tfj)

It seems quite useful and especially for a number of limesurvey implementations, where sensitive information might be stored.
Bearing in mind that the limesurvey application can be used as a voting system, we would like to propose the multiple (serial) key encryption of the responses, than just a single key encryption.
That would ensure the maximum security of the results and make the decryption proccess possible only when all involved parties can provide their private keys.

Has there been any movement on the idea of an encrypted field type? We're implementing Limesurvey in a University setting and this would solve a number of IRB headaches. I'm a mediocre php programmer but willing to try my hand at this as time allows.

Thanks for the ideas on encryption. Below I'll try to go into some concerns on encrypting data.
When applying encryption there are several attack surfaces that need to be considered:
- Database layer
- Application layer

When using symmetric encryption, encrypting data in the database only protects us from attacks on the database layer. Any attack gaining access to Limesurvey will also gain access to the key(s) used.

When using asymmetrical encryption we are able to make data secure from being read by the application itself, thus rendering any attacks on the application layer useless.

Since the database layer can, in most cases, be protected by simply denying all outside access I feel (symmetrically) encrypting the data inside the database is not the most efficient way to increase data security.

That said, applying some kind of asymmetrical encryption is definitely an interesting idea. It does have some downsides though:
- Limesurvey will not have access to the stored data, breaking any kind of dynamic texts and conditions for surveys that are not finished in one go. (ie. that have their data written and read from the database between start and finish, for example when resuming from a token link).
- If we don't want the data to be stored (unencrypted) in memory a lot of changes are required to the core to ensure that data is encrypted as soon as possible after receiving it.

In 2.10 we will introduce question plugins, these are question plugins will allow third party developers to create question types and will definitely allow you to add both symmetrical and asymmetrical encryption to individual questions.

For 2.05 there are several features that might aid you in developing a solution that is secure enough (in security nothing is ever really secure, it is secure enough or not secure enough).

- use the afterSurveyCompleted event to get the data, encrypt it and store / send it. When using the default plugin getters and setters this won't be the most efficient approach when exporting big data sets later, but it will work and be secure.
- if you want us to we can add a function to the plugin api to allow you to delete responses, your plugin could then delete the response after having encrypted and stored it.

Thanks again for the feedback, and keep the suggestions coming!

(disclaimer: While being part of the team, the opinions stated are my own and don't necessarily reflect the opinion of the Limesurvey development team as a whole.)

I just came across this post from a while back about custom hooks. I am trying to integrate limesurvey with a medical application, and I'm very interested in your #3 and #4 hooks. We had been using the newtoken.php for limesurvey <2.0 but it's not as secure as we would like. Are these hooks something you could share with myself and the community, or is it something you need to keep private?

I'm specifically trying to pass users into a survey in a secure method, without the possibility of users viewing their browser history and getting back into a previous survey. Also some data in the survey is sensitive, so it can't be visible on the URL in the browser history.

Any insight from you or anyone else on this site would be greatly appreciated.

Thanks,
Natehelper schrieb:

From my perspective (learning hospital/university), the objectivity of an API would be to provide hooks to other API's (for example, advanced web services). These could include interfaces with print services and/or electronic medical records (like Epic).