If you run a forum using some off-the-shelf software, then you've probably noticed a lot of new registrations (and posts) from this forum spam software.
Most of them use a 10-character password, like "sFueJHf5if".
If your software doesn't hash password then it will be easy to spot.
But here is a way to weed out those registrations. It works for now. Since it seems to be able to beat captcha, there is one trick you can use to disable the registration.
Create an extra password field on your registration page and hide it using css property "display:none;".
On your registration page, you would normally have something like:
<form....>
<input ...>
<input ...>
<input type="password" name="password">
<input type="password" name="password_confirm">
...
</form>
With two password fields to make sure the user doesn't make a typo. That's pretty much a standard.
Add a hidden div, so your form would look like:
<form....>
<input ...>
<input ...>
<input type="password" name="password">
<div style="display:none;">
<input type="password" name="passwordzz">
</div>
<input type="password" name="password_confirm">
...
</form>
And on the server side, disable all registrations that have "passwordzz" filled out.
You can use any name, as long as the type of the input is "password".
It looks like XRummer fills out all fields in a form that have type "password" with identical random value.
Normal users would have "password" and "password_confirm" filled out, but "passwordzz" would be blank.
Registrations by XRummer would have all three fields filled out.
At least as of 12/31/9 it seems to be working.
In the future, it would be a good idea to randomize the names of your password inputs and include 10+ of fake ones hidden by the display property. That would make it harder for the authors of XRumer to make an update that would deal with it. If that fails, try using the "class" to hide the fields and set the display property in the external css file. That will make parsing and working it out a much harder task for the programmers of XRumer.
Also, as shown in the example above, it's best to "stick" the hidden password field in between the two real ones, not at the end of the form. It doesn't matter now, but could help in the future.
Most of them use a 10-character password, like "sFueJHf5if".
If your software doesn't hash password then it will be easy to spot.
But here is a way to weed out those registrations. It works for now. Since it seems to be able to beat captcha, there is one trick you can use to disable the registration.
Create an extra password field on your registration page and hide it using css property "display:none;".
On your registration page, you would normally have something like:
<form....>
<input ...>
<input ...>
<input type="password" name="password">
<input type="password" name="password_confirm">
...
</form>
With two password fields to make sure the user doesn't make a typo. That's pretty much a standard.
Add a hidden div, so your form would look like:
<form....>
<input ...>
<input ...>
<input type="password" name="password">
<div style="display:none;">
<input type="password" name="passwordzz">
</div>
<input type="password" name="password_confirm">
...
</form>
And on the server side, disable all registrations that have "passwordzz" filled out.
You can use any name, as long as the type of the input is "password".
It looks like XRummer fills out all fields in a form that have type "password" with identical random value.
Normal users would have "password" and "password_confirm" filled out, but "passwordzz" would be blank.
Registrations by XRummer would have all three fields filled out.
At least as of 12/31/9 it seems to be working.
In the future, it would be a good idea to randomize the names of your password inputs and include 10+ of fake ones hidden by the display property. That would make it harder for the authors of XRumer to make an update that would deal with it. If that fails, try using the "class" to hide the fields and set the display property in the external css file. That will make parsing and working it out a much harder task for the programmers of XRumer.
Also, as shown in the example above, it's best to "stick" the hidden password field in between the two real ones, not at the end of the form. It doesn't matter now, but could help in the future.
