View Issue Details

IDProjectCategoryView StatusLast Update
0003024Composrcore_cnspublic2020-03-28 01:44
ReporterChris GrahamAssigned ToChris Graham 
Severityfeature 
Status resolvedResolutionfixed 
Product Version 
Fixed in Version 
Summary0003024: Lost-password form privacy (and assorted discussed ideas)
DescriptionOn 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.
TagsRoadmap: v11, Type: Security
Attach Tags
Time estimation (hours)10
Sponsorship open

Relationships

related to 0002304 resolvedChris Graham Greater password reset flexibility 

Activities

Patrick Schmalstig

2017-04-09 14:55

administrator   ~0004973

Last edited: 2017-04-09 14:58

View 4 revisions

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.

Chris Graham

2017-04-09 15:02

administrator   ~0004974

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.

Adam

2017-04-09 20:17

administrator   ~0004977

Last edited: 2017-04-09 20:19

View 2 revisions

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.

Chris Graham

2017-04-09 20:19

administrator   ~0004978

That's an interesting approach.

Adam

2017-04-10 01:13

administrator   ~0004980

Last edited: 2017-04-10 02:31

View 2 revisions

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.

Chris Graham

2017-04-10 01:14

administrator   ~0004981

Good ideas.

Chris Graham

2020-03-27 02:50

administrator   ~0006488

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.

Issue History

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 Note Added: 0004977
2017-04-09 20:19 Adam Note Edited: 0004977 View Revisions
2017-04-09 20:19 Chris Graham Note Added: 0004978
2017-04-10 01:13 Adam 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 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