User verification

Rework needed, want to help?

Due to time limitation, I cannot pursue the ongoing development at the moment. If someone wants to help, contact me.

The next branch is intended for some basic changes.

API integration first

User verify will now integrate with almost any popular Drupal API to allow for as much customization as possible.

Unpredictability

All-new central power will consist of many randomized, unpredictable and site-specific cloaking and obfuscation.

Intransparence

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.

Role-based

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.

Token-driven

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.

What instead?

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.