View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003024 | Composr | core_cns | public | 2017-01-11 10:34 | 2020-03-28 01:44 |
| Reporter | Chris Graham | Assigned To | Chris Graham | ||
| Severity | Feature-request | ||||
| Status | resolved | Resolution | fixed | ||
| Product Version | |||||
| Fixed in Version | |||||
| Summary | 0003024: Lost-password form privacy (and assorted discussed ideas) | ||||
| Description | On embarrassing sites someone could use the lost-password form to see if some member is registered on the site. (It could be someone else registered them and didn't activate though.). Ideally we want to do the following: - Send out an email to any address, saying whether there is an account or not in that email - In the message by very generic, just say an email has been sent to the address which will initiate the reset process, if the account exists - Add CAPTCHA to stop bots Giving a generic response meets the privacy requirement. Sending the email helps the user know if they are trying to reset on the wrong email address (many people use multiple addresses). / help them know if they are getting spam-filtered CAPTCHA stops the increased spam risk. | ||||
| Tags | Roadmap: v11, Type: Security | ||||
| Time estimation (hours) | 10 | ||||
| Sponsorship open | |||||
| related to | 0002304 | resolved | Chris Graham | Greater password reset flexibility |
|
|
I think the lost password feature should be improved even further. My website was recently attacked by someone trying to gain access to accounts on it. One of their methods was to spam-use the lost password feature, which resulted in many of my members receiving several password reset links. And this was not a bot either from my analysis using smartlook... this was a real person doing it... so CAPTCHA would not have stopped them. Perhaps lost password can only be used for one account per IP per (insert amount of time here). And if an account has already had a password reset used, prevent another password reset from being sent to the same person until/unless the previous reset link had expired. This should be optional though, because some people may desire to allow the lost password to send multiple reset links if, say, someone's reset link never made it to them. The messages given to users using the feature should be clear if a limit is in place that they must wait X time before using the lost password feature again. |
|
|
I'm not sure what you could do though. My fiancee recently had this happen on amazon.com, so even Amazon don't know how to solve the problem. You can't try and put a limit on particular IPs or sessions, as they could use a cookieless TOR browser. |
|
|
Amazon is quite a humongous site, I reckon most Composr communities are small to medium, so perhaps adding the password requests into the staff validation queue initially could be an option. That way members don't get spammed and the staff can check the IP etc before sending the reset email. Just an idea. I would rather wait for staff action than have my account compromised. |
|
|
That's an interesting approach. |
|
|
It was mainly an idea to stop the system spamming reset emails. Given the validation queue exists it might as well be used to let an admin or staff determine if the request seems legitimate before allowing an email to be sent (rather than however many were initiated). Humans are more useful than robot overlords made of code, sometimes. And we have the audit trails and logs to help us. Might be a useful option for sites under attack, doesn't have to be on all the time or at all. Don't some sites send an email asking if you requested for your password to be reset? then the member has to click a link to confirm or deny that they made this request. I imagine a denial would lead the requesting IP to end up on the ban list automatically. Maybe an email like that could be sent by the staff if they are unsure, the normal reset email if they are sure, and no email if they believe it was a hack attempt with an option to place the requesting IP on the ban list. |
|
|
Good ideas. |
|
|
I'm implementing this now, but just my initial proposal. I do like your ideas on some level guys and want to thank you. But I also think on another level they are either overkill or impractical. I don't think someone's going to sit there solving CAPTCHAs repeatedly to do such low grade spam. And if somehow they are trying to do a hack, then certainly they could use TOR browser, so IP restrictions won't help. We could put a reset-timelimit on it, but I don't see what difference that'd make either - if one reset goes through and the hacker has access to their e-mail, job done. All extra restrictions would add bloat/complexity to the product, for no again in my opinion. We have to keep things as streamlined by making sure all our features are very justifable. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-01-11 10:34 | Chris Graham | New Issue | |
| 2017-01-11 10:34 | Chris Graham | Tag Attached: Type: Security | |
| 2017-01-31 12:21 | Chris Graham | Description Updated | View Revisions |
| 2017-04-09 14:55 | Patrick Schmalstig | Note Added: 0004973 | |
| 2017-04-09 14:57 | Patrick Schmalstig | Note Edited: 0004973 | View Revisions |
| 2017-04-09 14:58 | Patrick Schmalstig | Note Edited: 0004973 | View Revisions |
| 2017-04-09 14:58 | Patrick Schmalstig | Note Edited: 0004973 | View Revisions |
| 2017-04-09 15:02 | Chris Graham | Note Added: 0004974 | |
| 2017-04-09 20:17 | Adam Edington | Note Added: 0004977 | |
| 2017-04-09 20:19 | Adam Edington | Note Edited: 0004977 | View Revisions |
| 2017-04-09 20:19 | Chris Graham | Note Added: 0004978 | |
| 2017-04-10 01:13 | Adam Edington | Note Added: 0004980 | |
| 2017-04-10 01:14 | Chris Graham | Note Added: 0004981 | |
| 2017-04-10 01:15 | Chris Graham | Time estimation (hours) | 3 => 10 |
| 2017-04-10 01:15 | Chris Graham | Summary | Lost-password form privacy => Lost-password form privacy (and assorted discussed ideas) |
| 2017-04-10 02:31 | Adam Edington | Note Edited: 0004980 | View Revisions |
| 2019-06-27 18:58 | Chris Graham | Tag Attached: Roadmap: v11 partial implementation | |
| 2020-03-07 21:22 | Chris Graham | Assigned To | => Chris Graham |
| 2020-03-07 21:22 | Chris Graham | Status | non-assigned => assigned |
| 2020-03-27 02:50 | Chris Graham | Note Added: 0006488 | |
| 2020-03-27 02:50 | Chris Graham | Tag Detached: Roadmap: v11 partial implementation | |
| 2020-03-27 02:50 | Chris Graham | Tag Attached: Roadmap: v11 | |
| 2020-03-27 18:42 | Chris Graham | Status | assigned => resolved |
| 2020-03-27 18:42 | Chris Graham | Resolution | open => fixed |
| 2020-03-28 01:44 | Chris Graham | Relationship added | related to 0002304 |
