security Important upcoming changes: How to properly identify a resident

[Chaser Zaks]

When I say authenticate in this, I mean to take some information to confirm that A equals B(EG: Is Chaser.Zaks equal to Chaser.Zaks).

It is important to note that this isn't fully finalized and Linden Lab may change specific stuff, this is written based off what I know.

This isn't a Linden Lab notice, it is a resident to resident notice. Some things MAY BE INCORRECT. This is intended for primarily scripters to raise awareness they need to update their scripts to properly authenticate people via UUID. Please do not spread F.U.D.(Fear, Uncertaincy, Doubt) by skimming through this and spreading incorrect/inaccurate words in group chats.

If you already authenticate users by the UUID, then you don't have anything to worry about.

The change:

If you haven't seen it already, take a quick skim through 

Quote

7. The return of Last Names - You’ve asked for it (a lot!), so we will provide a way to customize your last name in Second Life! More details will be available later this year.

During a User Group meeting, it has been slightly confirmed(As in, it is the current plan, this may not be 100% the choice yet) to allow users to change their last name, and even first name. For scripters(Both LSL and external), this is a very big and concerning change.

We can normally authenticate residents by their username(EG: Chaser.Zaks, Saltyalt.Resident, Ebbe.Linden, etc), but because of this change, this is no longer a viable solution.

I have always been authenticating residents via their UUID. The UUID will never change. It is important to authenticate residents using their UUID.

 

What this means for existing content:

If you are a scripter, if you haven't already been doing so, authenticate users by their UUID.

If you are not a scripter, check that you can authenticate residents via their UUID. If you cannot do this, you will need to contact the creator.

If you are a web developer, APIs are planned to allow us web developers to authenticate and update information as needed.

 

Why this change is may be of impact:

If you authorize people to be in your parcel by their username, and they change their name, they may no longer be authorized to enter your parcel and get ejected.

 

Why this isn't a security risk / Why you shouldn't worry someone will take over your sim:

Once a username has been used(EG: Chaser.Zaks), it can no longer be used again, for example:

1. Say I have a security system which lets me use stuff like /1 eject <name>, or /1 ban <name>, and said security system only checks to see if the user who used it has the name "Chaser.Zaks"
2. I change my name from Chaser.Zaks to Chaser.Soupcanister
3. Someone sees this and thinks "I can use this to my advantage", So they try to change their name to "Chaser.Zaks"
4. They are told they cannot use this name as it has been previously used.

 

Estimated time frame of this change:

Not any time soon, but within this year likely. Think somewhere like October or December 2018. This is a big change and a lot of stuff needs to be changed internally to make sure it doesn't break stuff. I assume some things internally may be using name based identification.

 

Updating scripts:

Sometimes people may use llDetectedName or the Name parameter from listen. You should instead use llDetectedKey or the UUID parameters when possible. You do not need to change this for stuff that just says "Hello, <insert name here>".

For reference, this:

string thePowerUser = "Chaser Zaks";

default{
    state_entry(){
        llListen(1, "", "", "");
    }
    
    listen(integer channel, string name, key uuid, string message){
        if(name == thePowerUser){
            /*Do important things here*/
        }
    }
    
    touch_start(integer detected){
        if(llDetectedName(0) == thePowerUser){
            /*Do important things here*/
        }
    }
}

Should become:

key thePowerUser = "796b1537-70d8-497d-934e-0abcc2a60050";

default{
    state_entry(){
        llListen(1, "", "", "");
    }
    
    listen(integer channel, string name, key uuid, string message){
        if(uuid == thePowerUser){
            /*Do important things here*/
        }
    }
    
    touch_start(integer detected){
        if(llDetectedKey(0) == thePowerUser){
            /*Do important things here*/
        }
    }
}

 

If you need assistance with this:

Please send me a message In-world with the affected script/object with full permissions. I will upgrade the script for you free of charge. I am unable to fix products that are no modify. Please do not kill the messenger.

 

Edited March 24, 2018 by Chaser Zaks
Clarification

[Nova Convair]

Nobody knows anything at the moment - so I will not waste my time with it.

Once it's known what happens - then it's time for solutions.

Bye for now

[Innula Zenovka]

While I agree with the general tenor of the advice above, I am going to hold off rescripting a lot of my stuff until I have futher and better particulars of what LL finally do and what new functions and api they give us.

The reason for this is that I find usernames a very convenient alternative to UUIDs, and far more user-friendly if I'm asking end-users to enter access lists on notecards for a script to read in the dataserver event.   This is particularly the case since it's trivially easy to turn both legacy names like "Innula Zenovka" (though I guess they won't be "legacy" any more) and more recent names -- in both the "InnulaMk2" and "InnulaMk2 Resident" formats -- into usernames, by using something like 

string strUserName = llDumpList2String(llParseString2List(llToLower(name),[" ", "resident"],[]),".");

Presumably usernames are going to continue, so if InnulaMk2 pays a fee and changes her name to Innula  Smith (or whatever new last name is on offer), llGetUsername will return innula.smith, and that will be uniquely tied to InnulaMk2's uuid.

The worst that can happen, it seems to me, is that if I change my name, then the configuration cards will need rewriting.   

However, since we're told that LL will probably provide us (at last!) with an api that allows us to resolve first name/last name into uuids, I may very well find myself scripting something to use that, in case someone on an access list changes his or her name.   But I can't do that until I know what the new function is like.

ETA: What Nova said far more succinctly than I could.

Edited March 24, 2018 by Innula Zenovka