Dependency Graph
View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
10373 | Bug reports | Security | public | 2016-02-10 10:12 | 2020-03-13 18:46 |
Reporter | gmambro | Assigned To | cdorin | ||
Priority | high | Severity | minor | ||
Status | closed | Resolution | open | ||
Product Version | 2.06+ | ||||
Summary | 10373: Partial survey saving sends cleartext password in notification email | ||||
Description | When a partial survey answers are saved an email is sent containing the chosen password in clear text. More over the user is not warned in advance that his/her password will be sent in clear over a potentially unsecured channel. The given link should contain a token or a hash instead of a password and the password should not be printed in the email (unless it is a password recovery procedure) | ||||
Additional Information | |||||
Tags | No tags attached. | ||||
Bug heat | 264 | ||||
Complete LimeSurvey version number (& build) | 07702db54e77ce5ff4fc486f86b4 | ||||
I will donate to the project if issue is resolved | No | ||||
Browser | any | ||||
Database type & version | any | ||||
Server OS (if known) | any | ||||
Webserver software & version (if known) | any | ||||
PHP Version | any | ||||
What good would a token or hash be? Maybe add a checkbox? "Send password to my mail in clear-text." |
|
Need discussion. |
|
Token or hash to avoid sending password in clear-text, even in the generated URL. |
|
Yes, but how would you use the token/hash? Unless the user has a secret key he/she has to remember to unhash the token (then we have to use two-way hash algorithm), it's useless. |
|
Case token: the user enters only the email address, LS creates a random password (ala token) and uses it as it done now (pro: no risk the user discloses a valid/sensible password) Case hash: the user enters a password, the password is optionally sent the user (e.g. he/she can with a checkbox). The URL becomes something like this "/survey/index/sid/{$surveyid}/loadall/reload/scid/{$scid}/loadname/".rawurlencode ($_POST['savename'])."/loadhash/".rawurlencode (hash('sha256',$_POST['savepass'])."/lang/".rawurlencode (App()->language) |
|
Hi, If we hashing password : we can not send a link to retake it. We need to tested hashed password vs DB password. Maybe move "save" system in a core plugin allow different solution more easily. |
|
IMHO password are already stored as hash |
|
@gmambro : yes and we test We don't have to send hashed password clearly : it's the same issue . An option to show or not the password in save link ? |
|
We can just hash the hash and embed it in the link. |
|
But c_schmitz : it's the same : send the hashed password is a security issue too. One time hash is another idea with delay. |
|
It sure is, but we are not a banking application - but many users use the same password for several purposes - hash of a hash is much better than a clear text password and cannot be cracked by a rainbow table approach. |
|
Maybe best : link to load + information Somethink like that: Just remove any onfoirmation : leave only the reload link ? |
|
They will forget their password for sure, lowering the response rate. |
|
OK, But then hash it with something other : date or random. And add the date/random in saved table. Think we don't have to send just hashed password : hashed pasword is same for same password. Different hash for different save with sema password seem better. |
|
+1 for salts. |
|
This version of LimeSurvey is not longer supported. Please check so that the issue is fixed in a more recent version of LimeSurvey. If it's not, please reopen this bug report. Thank you. |
|
Date Modified | Username | Field | Change |
---|---|---|---|
2016-02-10 10:12 | gmambro | New Issue | |
2016-02-10 17:07 | ollehar | Note Added: 34833 | |
2016-02-10 17:08 | ollehar | Note Added: 34834 | |
2016-02-10 17:08 | ollehar | Assigned To | => ollehar |
2016-02-10 17:08 | ollehar | Status | new => acknowledged |
2016-02-10 17:14 | gmambro | Note Added: 34835 | |
2016-02-10 17:21 | ollehar | Note Added: 34837 | |
2016-02-11 09:38 | gmambro | Note Added: 34879 | |
2016-02-11 10:12 | DenisChenu | Note Added: 34885 | |
2016-02-11 10:19 | gmambro | Note Added: 34888 | |
2016-02-24 12:19 | c_schmitz | Assigned To | ollehar => c_schmitz |
2016-02-24 12:19 | c_schmitz | Status | acknowledged => assigned |
2016-02-24 12:19 | c_schmitz | Fixed in Version | => 2.5 |
2016-02-24 12:20 | c_schmitz | Fixed in Version | 2.5 => |
2016-02-24 13:02 | DenisChenu | Note Added: 35649 | |
2016-02-24 14:05 | c_schmitz | Note Added: 35652 | |
2016-02-24 14:08 | DenisChenu | Note Added: 35653 | |
2016-02-24 14:09 | DenisChenu | Note Edited: 35653 | |
2016-02-24 14:16 | c_schmitz | Note Added: 35656 | |
2016-02-24 14:16 | c_schmitz | Note Edited: 35656 | |
2016-02-24 14:23 | DenisChenu | Note Added: 35657 | |
2016-02-24 14:28 | c_schmitz | Note Added: 35658 | |
2016-02-24 15:02 | DenisChenu | Note Added: 35662 | |
2016-02-24 15:24 | ollehar | Note Added: 35663 | |
2016-02-24 15:30 | c_schmitz | Summary | Partial survey answers saving uses clear password => Partial survey saving sends cleartext password in notification email |
2016-04-04 13:22 | c_schmitz | Status | assigned => acknowledged |
2016-04-04 13:22 | c_schmitz | Priority | normal => high |
2016-04-04 13:24 | c_schmitz | Assigned To | c_schmitz => |
2016-09-07 13:07 | c_schmitz | Relationship added | has duplicate 11631 |
2019-09-23 12:18 | c_schmitz | Status | acknowledged => confirmed |
2019-11-14 21:39 | cdorin | Assigned To | => cdorin |
2019-11-14 21:39 | cdorin | Status | confirmed => assigned |
2020-03-13 18:46 | c_schmitz | Note Added: 56468 | |
2020-03-13 18:46 | c_schmitz | Status | assigned => closed |