Developer Keys for 3rd Party Clients

I would like to retract my proposal... since LL changed their TOS on 3rd party clients.

x

Give it a few days.

Imagine somebody trying to distrupt another's SL viewer/tool ... what would i do, I would use his key and use it for restricted activities to ban him.

Secondly you don't need to create your own viewer you can inject in Second Life viewer in same way as I do to see SSL connection detail/credentials when I am debuging HTTP SSL to the bank of my web browser.

Using public&private key would be better proposal but still one can imagine making tools like copybot with injecting into SL viewer or its components instead of making separated app viewer.

For simplicity and proper security constrains i would suggest to avoid this thinking... till PC with separated hardware data encryptor with private key from main OS would come.. till then any client any viewer has to be treated as potentially dangerous and sensitive data(scripts...) should have be separated from SL viewer gathered data.

yeah but since no sane user would ever buy a comouter part that try to lock him out of his computer...

x

The (custom) client has to supply its key to the server, though. So someone wanting to steal it simply emulates the server behaviour on login (which is currently just 'wait for data and react accordingly' iirc), receives this data from the client in question and then parrots it to the real server, which has no way to tell that data from authentic client that's being emulated.

There's of course ways to maybe encode the handshake or whatnot, but since the protocol would have to be disclosed to 3rd party developers so they know themselves how to perform correct authentication, the point seems rather moot o.O;

I'm not following you. Let's say I'm a developer (I am). I want to develop bots, altruistic bots unlike CopyBot. So I apply for a developer key at the LL website. They send me a key in my email. At this point I'm the only one who knows the developer key.

I download the libSL libraries. After implementing their new developer key policy, Linden Lab was kind enough to update info on the libSL Wiki. Now I know there's a new field called "developer-key" in the XML-RPC POST sent to LL servers. As the wiki notes, the communication is encapsulated "in a TLS 1.0 (https) stream."
http://www.libsecondlife.org/protocol/index.php/Login

I load up Visual Studio .NET, use the appropriate libSL libraries, make my custom bot. THEN I hard-code my developer key into my custom client. My custom client is only on my computer, no one else has it. I compile it. No one else still has my key, right?

My new app is going to connect to https://login.agni.lindenlab.com/cgi-bin/login.cgi to login to Second Life. Now you're saying someone is going to "emulate the server behaviour on login."

When I run my app it's connecting to a https login script on LL Servers. Only I have my new application, only LL Servers are communicated with. So how is someone else going to steal my key unless if the network/computer is compromised?

If I give my application away that's a different story, but I didn't deal with that in this proposal. Right now I was just asking to implement the developer keys in their protocol.

Even if you're never selling your application, it's possible, if you're on any kind of shared network. Even if the network is implemented using a switch or uses encryption this attack will work... I first saw it implemented on a wireless network using 128 bit WEP* at a convention full of security experts, who were REALLY embarassed when suitably edited transcripts of their sessions were presented in the last technical session of the convention.

Here's what happens:

Your application: give me the address of "login.agni.lindenlab.com".
Your computer: Give me MAC address for IP-address-of-upstream-router. (ARP request)
Cracker: MAC address of upstream router is crackers-MAC-address (ARP response)
at this point every packet your computer sends out goes to the cracker's computer first
Your computer: (unrelated request)
Cracker: Forward (unrelated request) unmodified to upstream router
Your computer: Send DNS request for IP address of "login.agni.lindenlab.com"
Cracker: DNS response, Cracker's IP address
Your computer: (unrelated request)
Cracker: Forward (unrelated request) unmodified to upstream router
You're application: send packet to what it thinks is the login server.
Cracker: does whatever it wants to it, you have no idea, you're owned.

* This didn't involve breaking WEP, which requires a much larger traffic sample than is practical here, it took advantage of the fact that a wireless network using encryption is equivalent to a wired switched network... even with the updated WiFi security this attack is no harder. A switched campus network, a network at a cybercafe, a DOCSIS cable modem network, all these are equivalent and are equally exploitable.

hosts file:
127.0.0.1 login.agni.lindenlab.com

can you ever be sure what your application is trying to connect to is actually genuine LL server, once its copies get outside of your personal computer, like most of 3rd party tools and clients eventually would? After all, the idea is to let people use them. ^^

The other problem is that eventually, somebody is going to create a client that uses a developer key to connect to Second Life, and when that happens, somebody is going to use a packet sniffer to determine what that key is and simply copy it.

Security through obscurity is no security at all.

Anyone may acquire a developer key if they jump through the proper hoops - and since the keys are easy to sniff out, since they must be run on a client machine somewhere in order to be used at all, the keys can never be made secure. There is no way of knowing whether the key in use is being used legitimately, so therefore there is no way of even determining for certain that someone applying for a developer's key isn't up to no good in the first place. "Oh, some evil hacker stole my key. I'm completely innocent here."

So in essence, a developer's key or other license exchange connection scheme does not remove the snails from your garden - it simply moves the snail eating your tomato plant from one leaf to another.

@Argent

That's interesting. I didn't know that about shared networks. If a hacker is doing that on someone's network, the attack could do a lot more than steal an SL Developer Key. Https stream out in the open would be a big problem for a lot of online transactions.



If someone else has my app, they could make it do whatever they want. They still have to contact people in-game to distribute their malware version of the app, so it's just like stealing someone else's key. And yeah, that could happen, I'm not saying this system stops that.

BUT... If my key gets stolen, and LL contacts me about malware with my key, I think I would have an incentive to help LL with a customer list and a group of people who probably have my software to disassemble it. Before banning, they could look at my transaction history to make sure I'm not profiting from malware. It's a lot easier to handle abuse requests by a small group of the hacking community, then to answer abuse requests across the whole grid for Copyright Infringement (which they still will, but I think it would be less with my system, which is my opinion). If LL can't prove who it was who wrote malware with my key, I don't get banned... I might have my developer key invalidated/changed and the whole process starts all over again.



This is a deterrent, not a solution. There is no security through obscurity because there is no security. You can argue making hackers jump through the hoops will deter 0% of the hackers... but I think deterrents are helpful to mitigate damage to the SL community.

The main policy change is that LL can ban users who created 3rd party software which they deem as a violation. That's a deterrent, not a secure system. You can argue about the cost-benefit analysis of the deterrent, but you can't say if something can be worked around and LL will never catch them, that the deterrent has no benefit at all.

Email AOL. Ask them about the benefit of using a developer key policy. They probably think they get more benefit from doing it than it costs. Similarly I think LL would benefit with developer keys more than the small cost to change the protocol.

Actually... I don't think LL will do any of this. It doesn't fit with their vision of SL being the 'new internet.' So don't worry, it's not going to happen. LL is not AOL.

I think you don't understand the way libSL works.
libSL behaves the same way as the genuine Second Life client. There is no way for LL to know whether I am connecting to SL using libSL or the Second Life client.

A developer key would make sense if LL would provide their own API for accessing Second Life.

Yeah I know LL doesn't have an SDK, but they could still give out and then use keys in their protocol. I guess that is a little weird without an API... but yeah, LL changed their TOS so I'd like to delete this whole thread anyway.