SL User Create

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