https://bugzilla.wikimedia.org/show_bug.cgi?id=9838
Tyler Romeo <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #5780|0 |1 is obsolete| | --- Comment #8 from Tyler Romeo <[email protected]> 2011-07-17 07:33:11 UTC --- Created attachment 8793 --> https://bugzilla.wikimedia.org/attachment.cgi?id=8793 Use memcached to check the number of failed login attempts and notify the user. Hmm, what do you know, now that the bug has resurfaced I actually disagree with what I said before. XD Regardless, attached is a new patch with a number of differences from my old patch: 1) Using memcached instead of a session variable as suggested because of the numerous advantages it has (such as if the user resets the session). Made the functionality similar to how login throttling works. 2) The wfGetIp will throw an error if it doesn't actually return an IP, so there's no need to have that checked when notifying the user. 3) Improved my previous notification, since the last one I wrote was pretty bad. 4) Removed the error that is returned if the user does not have an email. The behavior should be that the wiki stays silent b/c all throwing an error does is tip off the hacker that the user has no email and will never be notified about the failed password attempts. 5) Removed the hook for notifying the user. IMO it seems pretty useless. If anything, a hook MIGHT be useful in the actual mechanism for measuring the number of password attempts, but that's an unrelated issue that could be raised in another bug report if the issue arises. 6) I implemented a system where the user receives one email after the first three failed attempts and then a more serious email if the problem progresses, mainly because this functionality will (and should) not notify the user constantly, so the user may choose to ignore the first email while failed password attempts to continue in the background. One other thing I would ask for some comment on is the possibility of having multiple sets of password throttling settings: the current functionality of password throttling is so that no IP can try too many password attempts in a given amount of time, but what if a cracker continues to try password upon password? IMO, it would be helpful to, rather than just have the person wait 300 seconds to begin trying, have the possibility (though not necessarily the requirement) of more serious throttling as the failed password attempts continue. This is really unrelated and belongs in a separate bug report, but I figured I'd ask about it before making a new report and whatnot. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
