Today I saw an error that according to bugs.limesurvey.org/view.php?id=16122 is already fixed half a year ago.

But in my test the name and email of a token is not encrypted in the database. Where is that setting located?

I recommend to open a new bugreport with your LS4 version.
There are still issues around encryption. And LS4 is still not ready for production.

jelo wrote: I recommend to open a new bugreport with your LS4 version.

Before that I want to know how this should work. When the system should encrypt name and email?

Jmantysalo wrote: Before that I want to know how this should work. When the system should encrypt name and email?

It muts be encrypted in DB : always.

It must be shown decrypted on browse and export toke, (an when using TOKEN:FIRSTNAME)

But maybe it's only my opinion ?

Else : just check on an already activated survey with 4.3.31 : after set crypted on attribute management : lastname, firstname and email was crypted.

DenisChenu wrote:

Jmantysalo wrote: Before that I want to know how this should work.

It muts be encrypted in DB : always.

I am not at all sure about this. If we have a small installation having webserver and database at the same machine, then the evil hacker gets both db and decrypting key at the same time. If we use external network disk, then we could encrypt everything in other level -- maybe encrypted DB, something like encfs for files containing DB or a block-level encryption.

(Btw, other thing is asymmetric encryption of responses. Survey maker could generate keypair, and put the public part in the server. Then the evil hacker would have no way to read responses given before the intrusion. I guess I must do a plugin for that sometime.)

Kind of strange to be able to encrypt first name but not last name and vice versa. Anyways, I'll continue testing and make a bug report.

Jmantysalo wrote:

DenisChenu wrote:

Jmantysalo wrote: Before that I want to know how this should work.

It muts be encrypted in DB : always.

I am not at all sure about this. If we have a small installation having webserver and database at the same machine, then the evil hacker gets both db and decrypting key at the same time. If we use external network disk, then we could encrypt everything in other level -- maybe encrypted DB, something like encfs for files containing DB or a block-level encryption.

I tell how it's constructed now, and how it must work now.

If you activate crypt option for fistname : it must be crypted in DB always.

personnaly i think it's only false security …