View Issue Details

This bug affects 1 person(s).
IDProjectCategoryView StatusLast Update
09580Feature requestsSecuritypublic2015-04-09 08:53
ReporterDeveloperChris Assigned ToDenisChenu  
Status closedResolutionwon't fix 
Summary09580: User password security issues

The current version of limesurvey treats user security in a fairly lax way

The area of greatest concern is the method for setting and resetting passwords.

1/ When a user is created a password is emailed to the user. This password SHOULD be a one time password The user should be forced to change the password upon first login.

The reason for this is email is an insecure transport. any intervening system can intercept and extract the password.

2/ When a user gets their password they cannot change it without being able to view all other users on the system

This is an issue where limesurvey is used across multiple agencies or organisations. It is inappropriate for a non admin user to be able to see all other users just so they can change their own password.

The correct place for this is to be in their preferences screen.

3/ Survey admins can see all users and groups

The issue is similar to above. A survey administrator should be able to add users and assign rights to those users for a survey. but they should not be able to see all users and groups

Perhaps they should be able to create their own groups.

Previously survey admins could not see all users AND could not add users who were already in the system. this resulted in an error.

Now they can see all users. EVEN if they don't have global user permissions!

What needs to happen is survey admins can only see and edit users for the survey they have security permisssions on.

If they need to add a user and that user is already in the system NO ERROR should occur instead they should be added and an email despatched to say they have been added.

In Summary

I can see that efforts have been made in the latest version to fix user security problems from previous issues but those efforts appear to be bandaids rather than well thought out fixes

An example of the 'bandaid' approach is the resolution to item 2 above where the fix was to simply give the user access to viewing all users without concern for the implications. this fix was documented here...

TagsNo tags attached.
Attached Files
2015-03-23 09_19_47.png (21,083 bytes)   
2015-03-23 09_19_47.png (21,083 bytes)   
2015-03-23 09_29_37.png (18,681 bytes)   
2015-03-23 09_29_37.png (18,681 bytes)   
Bug heat260
Story point estimate
Users affected %


related to 09568 assignedscoops Password strength 

Users monitoring this issue




2015-03-20 20:02

developer   ~31870

Last edited: 2015-03-20 20:05


Regarding (2/): I'm the author of fix to 09532 and I did concern for the implications. In fact, this bug was caused by another overfixed bug. Current git version behaviour has been the standard for a long time. After 09532 fix, a standard user without user permission can not see other users when he access user window to change his password. Could you describe how you get the situation you describe?

Regarding (3/): Again, I'm not able to reproduce the situation you describe. When modifying survey permission, he can see only users or groups he created.

Anyway, passwod policy could be certainly improved. In our organization, we have a patch to force users to use LDAP authentication. This way we solve other problems you don't mention in your "speech" (password complexity, expired passwords, etc) too.



2015-03-20 20:14

developer   ~31871


Regarding (1/): There is an option "display_user_password_in_email" to prevent passwords from being sent in email. See config-defaults.php.

And there is an authentication method (I have never tried) to use always one time passwords.



2015-03-23 00:23

reporter   ~31877

In the two above images it can be seen that the user can see all other registered users.
That user does not have any global user permissions set as can be seen in the second image.

With respect to the following settings
1/ display_user_password_in_email
2/ use_one_time_passwords

The first replaces the password with the message "Please contact your administrator". And then I assume the administrator sends the user their password via Umm email?

The second does not work the way I first envisaged. The password needs to be set directly in the database by a third party application (perhaps there is an api for it) and then it is expired after the password is used once.

It is most definitely a one time password. The user cannot get back in because it is deleted once it has been used.

Of course I could implement it in that way by manually adding a password to the DB and send instructions to the user to change their password once they have logged in. But there is no way to force it upon them (as the system currently stands).

With 100's of users this is an impractical solution.

I am sorry you thought my bug report/feature request was a 'speech' I was only trying to describe the problem in as much detail as possible without over doing it. I find providing less detail ends up in a to and fro until the actual problem is nailed. Too much detail (and stressing the important words) can be insulting as apparently I was. For that I apologise.

As to standard password complexity rules. Apart from length and ruling out the most obvious bad passwords I subscribe to this line of thought.



2015-03-23 01:29

developer   ~31878


Regarding your screenshots: Could you try to reproduce this situation in current git version? I tried and I couldn't.

Regarding passwords in emails: I agree with you about sending passwords in emails is not a good practice. In fact, I think the best option is not an one time password but a temporal URL to set a valid password. I just wanted to show you some workarounds for current version. You can prevent LimeSurvey to send password and use an alternative to emails or you can just force using LDAP as we do in our organization (in 2.06, this will be possible without code modifications).

Regarding one time password functionality: Sorry, I have never tried. No time to analyse it these days.

Regarding password complexity: I agree with you and xkcd. But there is at least a validation that could be done in every scenario: Preventing very short passwords. The ideal solution should be a way to configure validations. Every LimeSurvey administrator could choose for his instance.

Regarding your excuses: Thanks, accepted. Sorry if I was rude using the word "speech". As another regular user, thanks a lot for trying to improve LimeSurvey. Perhaps splitting your suggestions in different bug reports and closing this one would be a good idea.



2015-03-23 03:08

reporter   ~31879

I used git clone

No difference. Still the same as shown in my uploaded images

I thought perhaps it was because the user was assigned to the same surveys as the other users.

So I removed the user in question from all surveys. No difference I am afraid.

Not sure why you are seeing different from me. Perhaps the DB? Ours was a fresh install of build 141126. It wasn't an upgrade from a previous version.

Unfortunately we cannot use LDAP.

I have just done some debugging. It appears the application is working as designed which is a bit of an issue for me.

The reason why the users are showing up in the list is because they are in the same group (didn't think about that when doing my tests above).

The definition of usercontrolSameGroupPolicy only allows for show all in same group or show all regardless whereas I would prefer to see show group, show none or show all.



2015-04-08 17:27

developer   ~31962

Last edited: 2015-04-08 17:29

For user list : usercontrolSameGroupPolicy

It's done for this. Super admin always see all users.

But : actually in 2.06 : we can extend User Permission, then show/hide some user.

@aesteaban : i can take the "user form" system , adding New password system.



2015-04-08 17:32

developer   ~31963

Last edited: 2015-04-08 17:45

I move it to Feature request for 2 things:

  • LS is used more in "one entreprise" with some client, client have access to survey but not to user management, then usercontrolSameGroupPolicy does the trick.
  • For security : i already used one LimeSurvey with different DB and upload dir for each client. Usage of config.php depend on webserver name and go on.

PS2: LS3 DBAuthPlugin can be deactivated and replaced by something else. Then wait for LS3 seems better.



2015-04-08 19:22

developer   ~31967

@DenisChenu: In fact, this issue is assigned to me because I answered to initial comment. You can take whatever part of this issue you like. IMHO this issue should be closed. I have created two feature requests for issues treated here: 09598 and 09599. The only remaining issue treated just here is usercontrolSameGroupPolicy one but I think this is not a bug.



2015-04-09 01:10

reporter   ~31968

"i already used one LimeSurvey with different DB and upload dir for each client. Usage of config.php depend on webserver name and go on."

For maximum security I host a completely separate instance. but for the rest we are a large Gov Dept with many sub departments sometimes with common users having a separate instance or even just DB is not feasable.

I think its correct to make this feature requests, Not so much a bug as more "doesn't suit all use cases"..



2015-04-09 08:28

developer   ~31971

@DeveloperChris: Like asteban say : thig bug/feature is not clear. 3 problem (or more) in one report.

One is here : (for one time password User create)
Open another if needed.



2015-04-09 08:53

developer   ~31972

I can confirm the issue : 3/ Survey admins can see all users and groups in Survey Security settings.

@DeveloperChris: I close this one , please :
1: report the usercontrolSameGroupPolicy bug
2: report a feature (or strong support a featire) for password generation
3: report a feature for password updating

This bug report neeed different fix, then different bug report.

Issue History

Date Modified Username Field Change
2015-03-20 04:03 DeveloperChris New Issue
2015-03-20 20:02 aesteban Note Added: 31870
2015-03-20 20:03 aesteban Assigned To => aesteban
2015-03-20 20:03 aesteban Status new => feedback
2015-03-20 20:05 aesteban Note Edited: 31870
2015-03-20 20:14 aesteban Note Added: 31871
2015-03-20 21:49 aesteban Issue Monitored: aesteban
2015-03-22 23:43 DeveloperChris Issue Monitored: DeveloperChris
2015-03-22 23:58 DeveloperChris File Added: 2015-03-23 09_19_47.png
2015-03-23 00:01 DeveloperChris File Added: 2015-03-23 09_29_37.png
2015-03-23 00:23 DeveloperChris Note Added: 31877
2015-03-23 00:23 DeveloperChris Status feedback => assigned
2015-03-23 01:29 aesteban Note Added: 31878
2015-03-23 03:08 DeveloperChris Note Added: 31879
2015-04-05 23:04 aesteban Relationship added related to 09568
2015-04-08 17:27 DenisChenu Note Added: 31962
2015-04-08 17:29 DenisChenu Note Edited: 31962
2015-04-08 17:29 DenisChenu Project Bug reports => Feature requests
2015-04-08 17:30 DenisChenu Priority high => normal
2015-04-08 17:30 DenisChenu Severity @60@ => feature
2015-04-08 17:32 DenisChenu Note Added: 31963
2015-04-08 17:45 DenisChenu Note Edited: 31963
2015-04-08 19:22 aesteban Note Added: 31967
2015-04-09 01:10 DeveloperChris Note Added: 31968
2015-04-09 08:28 DenisChenu Note Added: 31971
2015-04-09 08:53 DenisChenu Note Added: 31972
2015-04-09 08:53 DenisChenu Status assigned => closed
2015-04-09 08:53 DenisChenu Assigned To aesteban => DenisChenu
2015-04-09 08:53 DenisChenu Resolution open => won't fix