An answer to, "Why was my contact information stored unencrypted?"

I've seen a lot of people on the forums reacting to the fact that LL stores unencrypted credit card information anywhere in their network, and reacting to the fact that real life contact info is not encrypted. I want to address why these two things are acceptable, reasonable, and, in fact, unavoidable. I'm not being an LL apologist here... I just want to explain some things to help stem the panic. I also don't want anyone to think that I'm at all happy about the fact that my personal data were compromised.

Both questions are related, but I'll take the first one first. When LL takes your credit card number, they have to store it somewhere. They need to be able to access it in some manner so that they can charge you in the future. They need to have access to the credit card number itself, the expiration date, and the name/address that goes with it in order to initiate a charge. So in some way, this information needs to be accessible at certain times (eg monthly) in order to use it to process a transaction.

This information could be encrypted. However, if it was encrypted, it would have to be possible for it to be decrypted at those billing times, easily, without human intervention. Encryption of this sort works a lot like locking a safe with a key: you put the secret information in the safe, lock it with the key, and then hold onto the key. The only way to get into the safe and get the information back out is with the key.

So if you want to automatically encrypt that data, you have to keep that key around and readily accessible so that you can use it to unlock the data when it comes time to use it. You can store the encrypted data (the locked safe) in a different place than you store the key, but what it comes down to is that an attacker can gain access to the locked safe and the key, and then they can get your information out. It kind of doesn't even make sense to lock the data up in the first place. Storing the key and the safe in the same place is tantamount to not bothering to use a safe.

To get around this little problem, what's usually done for billing systems and in ATM systems and the like is to construct a physical device that accepts a very limited set of information from a company like LL and talks directly to a credit card processing facility. This kind of device is probably what LL means by a "database where unencrypted credit card information is stored". LL can send in things like "customer NNN, credit card #### #### #### ####", and then "customer NNN, charge $XX.XX". The box might well only accept data in one direction from LL into it, but not even have a way of sending information out. This makes it very secure, since it's not possible to gain access to the credit card number at all from LL's side of the fence. It's a one-way road.

Another solution might be to use two-key encryption. A very terse summary of this field of cryptography would be to say that LL would be able to encrypt your credit card information with one key, and it would only be able to be decrypted with a second key, which is held by the credit card processing facility. Perhaps this is what's used to get the credit card number into the box, or the charge initiation information from the box to the credit card processing facility.

The question is why our personal data is stored in an unencrypted form in the database that the intruders accessed. Again, there's the problem of how to encrypt something and store the key in a safe place. LL would need to be able to read the data often (during technical support calls, when you access your account, and other times) and this would require that the encryption key be readily available. It's not obvious how to keep that key readily available to the programs that would need to decrypt the personal information in the course of business while not making it very easy for an intruder to gain access to the key as well. Again, storing the safe and the key in the same place makes the encryption pointless.

What it comes down to is this: if LL accesses the information during the normal course of business, an attacker who gains access to their systems can also gain access to this information. Even in an ideal situation where some way of storing the key in a place inaccessible to attackers is discovered, all an intruder would need to do would be to place themselves in a position to be able to watch LL's internal network traffic and then cause an action that would result in an access to your personal data. That's as easy as calling technical support and claiming to be you; LL would access your account simply to see your name and know what questions to ask you to verify your identity, and that could result in allowing an intruder to catch a glimpse of your data as it flies by.

In short, while I'm very concerned about this breach of security, I don't see anything out of the ordinary or unacceptable in the fact that contact information and credit card information are stored unencrypted in the manner that LL is implying. Encryption is not a panacea. It's not perfect, and it's not always feasible, and in some cases it's simply not the right tool for the job.



[Before I get flamed: I've studied in the computer network security academic field, although I do not hold a degree in the subject. I'm an experienced system administrator concerned and well versed with computer security and data encryption. I know I've simplified a lot of things here and glossed over some important points, but I think the underlying points are valid and should be helpful to SL residents not versed in computer security.]

When I signed up to be a credit card merchant, I remember there being a data security clause detailing how I had to store credit card information, and what information I was allowed and not allowed to store. True, I do not remember the entire document word-for-word, but I do remember there being something in there about storing unencrypted card information on network-accesible servers. It said not to.

And I'm not sure what LL means when they say our unencrypting payment information is on a server that only gives information "one-way," either. What stops it from going the other way? A firewall? That's what hackers do -- they get around firewalls. Closed ports? That's also what hackers do -- they reroute ports and send data through seemingly innocent ports.

While your arguments that encryption CAN be broken(oh by the way so can the lock on your front door/car) are valid. It doesn't mean it doesn't make good sense to make it as hard as is reasonably possible. And I don't see any leaving their house or car unlocked because someone could get though anyways and hey I need access through that door.

LL has had a "history" of being hacked, on the main grid at least, or so thats whats been said by LL, why hasnt better security measures on our behalf been placed on our personal information? Im sure its two entirely different things, but still it makes me wonder what kind of business is being run there, i guess hind site is 20 20

Aaron, I'm basing my guesses about the place where our credit card numbers are stored on this answer from Robin: /139/f7/136052/1.html

So our information is stored in an off-network vault that even Lindens don't have access to. That tells me that it's probably something like one of the hardened pieces of hardware that are used in ATM networks. I don't think there's any need to worry that they're also just storing our credit card numbers in some MySQL table somewhere.



cinda, SL grid attacks and a breach of the actual linden lab network are two entirely different things.

A protocol. For example, imagine a web server working like this:

To add a card you do:
http://example.com/billing?cmd=add_card&customer=34&number=234234324

To charge the card you do:
http://example.com/billing?cmd=charge&customer=34&amount=25

This server wouldn't give you any way to read a card number. You can only store new ones, and charge a customer by ID. Only of course an actual device of this kind wouldn't use a webserver, but something more like a connection over the serial port. That'd be the only way to talk to it, and it simply wouldn't have any functionality allowing to get a list of cards from it.

Deleted