Il 01/03/2013 23:03, Kevin Smith ha scritto:
On Fri, Mar 1, 2013 at 9:59 PM, Marco Cirillo <[email protected]> wrote:expecially to the "high usage" ones (possibly more, those with unprotected IBR)... Did you actually ever make a census of how many of your concurrent users are actual human beings..?It's not immediately clear to me how one would reliably do this - do you have any suggestions?Finally, moving forward on the "how to protect account registration", there're several very effective measures one of which is CAPTCHA (and that needs to be done right, implementations like ejabberd's .. just aren't appropriate ..) but alone that doesn't do it obviously, you should put some more verification layers after that. I personally employ a long-strict captcha on the site form, plus an additional e-mail token verification and several timeframe checks (e.g. the user has to verify the account within 5 minutes and has to do some copy & pasting...).This sounds very thorough (and entirely reasonable). Is your setup for doing this generally available so other servers could take advantage of similar systems? /K
Well Kevin beside "greeting the target" (before or after), they may be very clichy... but 2 enough effective ways to profile bots in my opinion are: - They tend being either incredibly idle or incredibly active, and usual have sudden activity bursts (idleness is to be treated with care and checked with other factors...) - They tend doing stuff a normal user wouldn't do (e.g. large amount of random service discoveries, which could reflect on servers with a high amount of non human beings having a way larger s2s connections number for instance) - They could have very large rosters or, very empty ones (as usual treat the latter case with care...)
For the 2nd question, tools and instructions not yet (but I may port something for Prosody in the future).
Although it could be not hard to replicate as the web form is a very simple Drupal form and uses Drupal facilities to create the Captcha. So basically while the webstack deals with captcha and sending e-mails to the user, the xmpp server has to deal with token generation/verification plus timeframe checks, this is the simil-workflow:
:: User submits the CAPTCHA protected form -> the webapp sends a request to the xmpp server<- xmpp server performs timeframe/additional checks and replies the webapp either with the token or an appropriate error. if successful the xmpp server awaits user verification. :: On success the webapp sends an E-Mail to the user on how to complete the registration, else it returns the server error. :: The E-mail to the user should contain the verification frontend of the xmpp server, a web interface's URL usually, the token and specify that the token should be manually supplied (e.g. copy & pasted into a form) to the xmpp server's verify interface within the admin desired timeframe before it becomes invalid (the shorter t the better..). And that leads to the final step.
=> User verifies using the xmpp server's interface, supplying the token.<= Server either report the success or error (wrong token or expired) through the said interface.
Marco.
smime.p7s
Description: Firma crittografica S/MIME
