Update: 3.x branch to start soon, sunset for all others
Since the hitherto concept of user_verification has lost its anti-bot effects, all still-current branches will no longer be developed. Instead, a Drupal 7-only 3.x branch will soon go alpha. To emphasize this, the project page will also be revised and legacy information has already been minimized. If you need documentation on legacy branches, please check the readme files.
While the new release is still volatile, the following will found the new conceptional base:
- API integration first
- User verify will now integrate with almost any popular Drupal API to allow for as much customization as possible.
- All-new central power will consist of many randomized, unpredictable and site-specific cloaking and obfuscation.
- The verification process will no longer provide any obvious triggers but instead run entirely in the background, which makes it hard to analyze a specific site's actual process structure at all.
- The complete verification process reflects in permission roles, allowing for unlimited granulation and individual ambiguity. You can use it to construct tarpits, honeypots, observation mechanisms, fake permissions - all from the backend without need for coding.
- User-unique, unobtrusive challenge and trust-application links, hints, messages and related information is presented in individual token replacements. Place them anywhere in your individual site, into blocks, messages, emails, arbitrary fields, wherever.
Why verify new users?
Once your site reaches a minimum popularity, or even before that, it is obligate that the first registration spam bots add you to their crawling lists and schedule your site for mass-entering. The patterns vary, but in the end the intention is clear: Acquire the privileges to publish anything visible to the public, spam your users with PMs and whatever (they figure) might draw attention. There are, of course, far worse intentions. However, auto-granting any publishing access - be it just a user profile page - without any substantial validation is something you do not want to do.
What is wrong with captchas and verification emails?
Drupal, as any popular framework and application, makes it easy for spammers to tailor bots which join your site and annoy your serious users. This is due to the simple fact that most protection concepts base on automatted mathematical (and thus predictable) tasks and patterns. All of them easily to study in the open source code documentation and as easy to "reverse-engineer". It is even worse with email confirmation: Most systems even help their opponent by delivering a trigger at no cost. Take any example, it is obvious: Automatted spambot defense is just like fighting fire with fire. In the best case, it is also a bit of cat and mouse, but you would not underestimate cats, would you.
While this is bad news, there is good news too: Just this is where we can actually beat them, if at all.
There is at least two kinds of of things spambot( dev)s hardly like: Unpredictability and patterns hard to analyze. This is what user verify primarily does:
- Work almost invisibly
- Cloak captchas and shuffle challenge forms
- Trigger verification process steps randomly
- Allow for a lot of site-specific customization (which kicks your site straight off any script tailored for a vanilla Drupal, e.g.)
- Obfuscate any challenge-related link and ID by using unobtrusive and site-specific, randomly generated patterns and even shuffling publicly explorable form item IDs while mapping their originals transparently in the backend.
Base line: The most important component in the individual verification process is your actual site and what you explicitely configure. And some random stuff.
How does it work
User verify is best described as a "moderation workflow for users". This means, instead of reacting on content generated by users (classical moderation), we will moderate the actual users before they can generate any visible content. (This does not mean that additional content moderation is no good idea!)
To easily configure permissions and anything else, the verification process is role-based. New users optionally obtain a quarantine role, which can be used for evaluation, observation or simply for confusion and ambiguation. Next is the actual verification phase where users may manually apply for trust and/or solve an (improved) captcha challenge. In this phase, dedicated tokens replace with individual information. So you could present a user the solution for his (determinated) captcha at a totally unpredictable place, or prepare verbose descriptions on how to pass the challenge. Your creativity is the limit.
Issues and feature requests
For any requests, please use the issue queue. Please be detailed and helpful. If you report a problem and suggest a constructive solution at the same time, you may experience some preference.
This module is brought to you by HiRN. You will be surprised to learn that any support beyond the "free and best effort" model here is of course available - there, on request and at a price. You are, aren't you.
- Maintenance status: Minimally maintained
- Development status: Under active development
- Module categories: Administration, Spam Prevention, User Access & Authentication, User Management, Utility
- Reported installs: 402 sites currently report using this module. View usage statistics.
- Downloads: 3,515
- Automated tests: Enabled
- Last modified: December 2, 2014