Description

Need to automatically register new users on a WordPress site with their Second Life® avatar names? This plugin allows you to do so, by exhibiting a script that you can copy and place into an in-world object. Users just need to touch the object to get automatically registered; if they are already registered, they will just get a link to your site.

New users will receive a password via the Second Life Instant Messaging Service, as well as a link to tell them the URL for your site. The new profile will include their avatar name as a login and their SL profile picture (if available via Web) will become their WordPress profile picture. If you have some special meta fields enabled on your WordPress profile, they will be filled in with some data from SL as well (e.g. location).

Security

First of all, please take into account that there is no absolute fail-proof solution. Hackers will definitely be more creative than I am in preventing them to override security to register with your site. If you’re afraid they might subvert your system and register accounts on your WordPress site, DON’T USE THIS PLUGIN!

If you’re bold enough to try it out, read on.

This plugin was designed for having multiple locations for SL residents to register with your WordPress site. The caveat is that this will require you to provide them with the LSL script which you copy from the plugin’s main page. Of course the script can be made no-modify and no-transfer, and so nobody will be able to read it, but we all know there are means to get access to it if someone really, really wants to (specially on OpenSim-based grids).

So there are four levels of protection in this plugin. Please note that three of them are possible to be forged; the fourth one is a bit more tricky but not totally impossible to subvert; how you use them all together is up to you, depending on how widespread and flexible you wish residents to register with your WordPress website.

The first level is a cryptographic signature. This is set from the plugin’s admin page (actually you have two signatures; one long string with random garbage, and a 4-digit PIN code). All in-world requests need to be signed or the plugin will refuse access; this prevents anyone not knowing your secret key and PIN and trying to simply send a forged HTTP request to be refused access.

But keys can be compromised. Your first line of protection is simply to delete the culprits — all objects registered with your WP site will be listed, and you can simply delete the objects from the “Objects” tab, and change the keys. The plugin will also send a remote delete request. Of course, a hacker having access to the script will be able not only to figure out the original keys but also to remove the code for the remote deletion command. And if you have spread out registration objects all around SL and OpenSim grids, changing the keys will prevent all objects from working, which might not be feasible.

So the second level of protection is to restrict registration objects to certain avatars (we’ll assume they’re the only ones you deem to be legitimate). You can, for instance, just limit objects to be owned by you and your close friends or associates (or just your alts). This means that a hacker will not be able to create an object and place a hacked script inside; SL (and OpenSim) send the object owner’s name, and the plugin can refuse requests from anyone not on the list. On the security page, this is the first area (Allowed avatars (for registration objects)). There is no limit to the list.

This can be easily subverted: if a hacker knows your avatar name and knows what keys and PIN are in use, they can register on a OpenSim grid with your name and continue to create accounts on your WP site.

A related protection is to ban some avatar names from ever registering again. This is the second area. Note that this doesn’t affect who can create registration objects and register them with your site; it prevents avatars from creating a login on your WordPress site. A banned avatar will be unable to create a login ever again, but they might still have an active registration object, and this area will not prevent others from registering via their object (meaning that the hacker will be able to create alts to log in).

Also, please note that things like avatar names and so forth are actually headers on the HTTP requests made by the in-world object, and these are sent by the SL grid itself (or the OpenSim grid). What this means is that hackers cannot launch attacks from within a grid (specially one that is not under their control), but they can create a piece of software that “pretends” to make a request from the grid but is actually running on a webserver with hacked headers.

The last level of protection tries to avoid the pitfalls of the three first protection levels. You can add a list of authorised domain names (full or partial) or IP addresses from which connections can be initiated. By default, when you install the plugin for the first time, it will only accept connections from SL’s grid — all servers in it should look like “simXXX.agni.lindenlab.com”, so filtering by “lindenlab.com” should only allow objects on the SL grid to register — all other grids will be banned. This will also prevent hackers from using their own webservers; headers can be forged, but the IP address from which the hacker is actually connecting is much, much harder to forge (I won’t claim it’s impossible, but it’s beyond most human beings 🙂 ). Even a hacker using a proxy or an “anonymiser” service to mask their original IP address will not work: you might never figure out where they are actually connecting from, but the plugin will know the request doesn’t come from Second Life (or one OpenSim grid you actually trust), so it will block it nevertheless.

Instead of blocking a whole grid, you can just selectively accept requests from specific servers (e.g. only from “simXXX.agni.lindenlab.com”). Under OpenSim grids, this might not work as expected, because the same server might actually host a lot of different sims under the same IP address, and it will not be possible to differentiate between them. Also note that you can use IP addresses and not domain names, for quick-and-dirty OpenSim grids who never even bothered to register a DNS address and just have IP addresses (like home-run grids). Linden Lab’s sim servers should all be accessible via DNS, so it’s safer that way; but they might shuffle sims around. The way to figure that out is by taking a look at “About Second Life”, which should give you the DNS address of the sim you’re on.

So what would be the maximum level of protection?

• Making sure that nobody knows your keys and 4-digit PIN
• Restricting the registration only to yourself
• Limit the access from a single grid or even a single sim

Again, this is not 100% secure, but should give you pretty much the same level of protection that WordPress itself provides: after all, if it’s too difficult to subvert this plugin’s authentication system, a hacker might try to register directly to your site, bypassing this plugin. These days, this is rather hard to do as well.

Also note that new users are created with the “Subscriber” role. This gives them the ability to post comments and create a profile, that’s all. Of course, the ability to post comments also allows them to spam you…

Hackers might also try to launch a Distributed Denial-of-Service attack against you, but, again, this is pretty much impossible to do from within SL (LL’s grid is proofed against launching DDoS attacks from in-world). It can be done outside SL, but it’s far easier to attack the WordPress site itself.