URGENT! LL security exploit

Rash? It was exactly the right thing to do. Otherwise, chances are whoever got that data would now have logged into your account, and transferred all the cash. Bet they could also mess your inventory up a bit, just to annoy.

I reiterate, how do you know that, or are you assuming? Because it doesn't say that in the blog post. It's not an unreasonable assumption, but given how fast assumptions turn into "ZOMG HAXX!!" around here, it's wise to be clear about what's what.

But even with a bot net you arnt in fantastic form if say, the salt is a UUID.



Given the implementation of llMD5String() in LSL I think a 32-bit salt is a fair assumption although I wouldn't want to wager on how much of the potential salt space is actually used, or whether collision avoidance is in play.



Who cares? Using the open-source OpenSSL MD5 implementation, at 3Ghz, a Pentium D can MD5 upwards of 600MB, per core, per second, provided you can feed the bus fast enough.

That means at an average dictionary password length of 7 characters and an average salt length of 11 characters (colon + over half of all 32 bit values are 10 digit), the first MD5 is over 7 characters and the second is 43. Result: I can turn an average of nearly 12 million dictionary words into SL-hased passwords, per core, per second.

Those are rough, inaccurate numbers, but the real ones are also very large.



Again, that's not what the blog says. Where are you getting your info?

LL's fault, of course. Have you not been following along?

Jesus. I would have never known about this if it weren't for the forums. Blogs suck!

Pay attention. If the passwords are properly hashed, then resetting them without a plan in place to handle the edge cases was... wait for it... rash.

The information in the blog was, in my opinion, insufficient to justify resetting the passwords without better preparation. You are, of course, welcome to disagree.

The "real" problem is the loss of personal information and the potential for identity theft. The password hubbub is just noise that distracts from that. The "doomsday scenario" is someone successfully decrypting the payment info, not the passwords.

HOWEVER THAT IS VERY UNLIKELY! (Added because I don't want to be accused of starting a panic.)

I also read that. Probably one of the posts by Jeska.

Holy shit.

Encrypted payment info? Did the blog change? I swore all I saw was "encrypted password".

So, someone has my billing information, stored in some "encrypted" manner which could be as simple as ROT13? LL needs to answer questions on what was stolen and how it was stored like, now, before lawyers start getting called.

If you can find it, could you provide a citation please? I would very much like to have as much information as possible. As far as I can see, Jeska Linden has posted three different messages today (one several times), and none of them mention SQL injection.

However, the post here directly contradicts the blog on the topic of whether encrypted payment info was divulged.

The blog entry changed.

There was no mention of billing information compromise in the original blog entry.

"No credit card information is stored on the database in question, and that information has not been compromised."

But now -- they are saying it is stored? But "encrypted".

If an attacker had access to the database wouldn't he also get access to the salt? And wouldn't it then be possible to do an attack by checking if hashedpassword from DB equals md5(md5(dictionaryword) + saltFromHackedDB)? for each word in a dictionary?

edit: looks like Tuach Noh already answered this a few posts up, it's hard reading all the posts

A linden mentioned it yesterday when they were trying to find out what happened. (they didnt mention anything more than that)

The billing DB has always been seperate (thankfully) - but this isnt the first time someone's put a SQL injection against the SL website (and it's absolutely reprehensible that it's been allowed to happen again, especially since there was room to put in measures after the last incident) - last time it was the forums that were used as the target, this time it was something else.

I'm not too please that my personal information is potentially floating around out there - but - given the nature of this attack (via the website - which LL has now confirmed via Jeska's post), wholesale copying is going to be tougher than just screwing around with it, although I'd rather not take the chance given a choice.

On the topic of the passwords - the reset has eliminated the problem of someone performing a dictionary attack against the whole, which makes the point fairly moot - but a brute force attack against the whole DB would still take significant time (dictionary vs 630,000 users - less shared salt; not allowing for any kind of permutation which exponentially increases the complexity of the decryption), especially against stronger passwords. (Although I do agree - there is a serious problem with weak passwords with no permutations involved - which seems to justify LL's decision to do a mass reset)

-Adam

True, but worth some clarification, nonetheless.

Salt collision is essentially a force multiplier for the attacker, because it lets him encrypt a test word once and compare it to multiple encrypted passwords. Having no salt is the ultimate force multiplier; you can encrypt a test word once and compare it to ALL passwords.

The pseudocode for the algorithm Adam described would look about like this:

strPassword = "password";
salt = random_32_bit_integer();
str0 = md5(strPassword);
str1 = str0 + ":" + salt;
str2 = md5(str1)
strHash = str2 + ":" + salt;

Example, with salt = 12345:

strPassword = "password";
salt = 12345;
str0 = "5f4dcc3b5aa765d61d8327deb882cf99";
str1 = "5f4dcc3b5aa765d61d8327deb882cf99:12345";
str2 = "844f728efe6efbf8c4098dbf7dfadaaf";
strHash = "844f728efe6efbf8c4098dbf7dfadaaf:12345";

So strHash is what ends up in the database. If two users have a different salt, they can both be using "password" as their password, but the strHash values will be completely different. Example:

strPassword = "password"; // Same
salt = 67890; // Different
str0 = "5f4dcc3b5aa765d61d8327deb882cf99"; // Same
str1 = "5f4dcc3b5aa765d61d8327deb882cf99:67890"; // Different
str2 = "c1d5bb9eb89c4b835bfa4b69c6e2f685"; // Different
strHash = "c1d5bb9eb89c4b835bfa4b69c6e2f685:67890"; // Different

If every user's salt is different, one has to try encrypting "password" 630,000 times to find all the people who chose that as their password, which slows things way down. Unfortunately, they're usually chosen pseudorandomly, which leads to collisions (two or more people with the same salt).

As a force multiplier, salt weakness (in the form of collisions) increases the speed of an attack by a constant multiple, but that generally is not enough to affect the overall viability of the attack. Lack of a salt, however, can make that constant huge enough to render the attack trivial.

Incorrect. Hashing prevents the recovery of good passwords, but with more than half a million accounts there are going to be more than enough passwords that are breakable within minutes. No amount of hashing will make a password like your name, or "kittens" safe. The only passwords that are safe for a long time are those that are randomly generated and don't appear in the dictionary.

I use ones like "BahKahv8", and now switched to a fully random, 16 characters long ones like "Bo86dQwoDvarUTtX". But people with passwords like that are a very small minority, and you can bet 90% of the passwords in the database can be easily broken.

Oh no! Aces! Say it ain't so! I truly hope you are able to recover your account else I will be the last to bare the Spade name

Ah. So some people found about this before others.



Eh? What post? Jeska's post is a copy of the (original) blog post.



Not sure I agree with that.



But I definitely agree with that.



Yes.



Still moot, but nobody would bother with the stronger passwords. With 630,000 users, there's an awful lot of low-hanging fruit.



In the absence of any additional information, I suppose I have to agree that that's the most likely explanation.

Obviously if they need sample C++ code for a cryptographically strong password hash, all they have to do is ask.

My remaining concerns:

1) Was the "security question and answer" included in the leak?

2) When will I be able to change my security answer?

3) What is the feasability of the attacker decrypting the payment information?

#3 is a little worrisome. We know from LSL that someone over there has read RC5 but doesn't mind limiting it to trivial keys.

Sigh. I have an idea, how about if you actually read my posts before you dismiss them as "Incorrect?" (In other words, you're still not paying attention.) If you had, you'd know that I'd already said everything in your post.

Let me speak slowly and use small words.

If you arbitrarily (oops, big word, sorry) reset passwords, you force people to fall back on the secret question and answer.

You have moved your security away from the screen that says "choose a good password" and onto the screen where even half the people with good passwords entered "kittens" for a secret answer, because who cares, right?

You have done this at a time when there is a good chance you already told the attacker everyone's secret question and answer.

People's secret questions and answers cannot be changed.

You let people reset their passwords by calling up and giving their secret question and answer.

But the attackers might have the list of secret questions and answers.

Now you end up shutting the phones off for three days trying to figure out what to do next.

So you're in a bad, bad place that could have been avoided with a bit more planning. Say for example, two days' worth.

Conclusion: It... was... rash.



Are we meant to be impressed? There are a lot more printable characters than letters and numbers.

The assumption that the passwords are crackable within minutes is also not good, unless you can tell me what the algorithm actually is. Yes, Linden probably just got their asses saved by security through obscurity.

Well I think I’m now well and truly screwed.
For reasons I’d rather not explain I have used an alt for the last few months.
She has all my assets and to make natters worse she in turn has alts.
I can log in with my primary account but that doesn’t help me much.
I even tried to create a new alt and she even got the same password message.
Unless the old passwords are reinstated I’m leaving SL for sure this time.
The problem being that it is the alt that gets billed as the land owner, how do I explain this to a third world bank when I hardly understand it myself.

That's actually been like that for half a year at least cause when I joined I accidentally did that, not even knowing I was entering too many characters in my password (the registration form accepted it without warning after all) until I tried logging in the game for the first time

Right. An AMD64 3000+ 2Ghz does ~10 mill md5 hashes per second. So to check 280000 active users with a unique salt with a dictionary of 50000 words would be umm 50000 * 280000 = ~4 * 10^10 hashes? (4 * 10^10 hashes) / (10 * 10^6 hashes/s) would be 23 minutes? *sigh* I'm really too tired to think straight now.

Correct.


Bad conclusion. To even begin answering to the secret question you need to be in control of the mail account that'll get the email. Hint: Whoever got the password database doesn't have access to my mail server.

Yep, those people who gave out fake email addresses, and filled junk in the secret question answers are now screwed. Well, they should have thought harder.

LL had basically several options:

1. Do nothing. We wouldn't have all this mess in the forum, although it'd be a huge mess the moment whoever got the data started messing with the accounts. So not good.
   
2. Announce it, then do nothing. This seems to be what you suggest, and is nothing more than a variation of option 1. Additionally they'd have people screaming at them to do something and not sit there like morons, which would be an entirely reasonable position.
   
3. Reset password for all logins, rendering the attacker's database useless.
   

Granted, the shutting down of the phones was a bad move. But if they haven't done what they did now you'd have the attacker logging into various accounts and transferring cash. And there'd be also much screaming every time somebody thought their balance was L$1 off.

I don't really get what you think they should do anyway. The only sensible reason to this breach is to reset the passwords. It has to be done in either case, and the sooner the better. Delaying it would only give attackers more time to wreak havoc.


That doesn't really matter. What matters is that in any sane cracking program it'll take weeks to get there. If you're trying to crack passwords you go through the low hanging fruit first, and anything random is way down that list. It's not that it's uncrackable, but it's very doubtful somebody would find my password in two days by brute force when going through half a million accounts, unless they were targetting me specifically. In a year, maybe, but it's changed already so it'd be wasted effort.


Doubt it very much, this stuff is usually done with well tested, and very well known functions like MD5 or SHA1. Most databases already include a function for that, so it doesn't make much sense to roll your own.

Even more so, the algorithm can't be secret. Think about it for a little. The web site needs to check the password somehow. So, however they do it, whether it's using a database function, or something they came up with, that code is right there for taking. Rolling a simple password cracker is just a question of half an hour for a competent programmer.

This is a very interesting subject to be sure, but as Adam points out, it's entirely theoretical and not relevant in a post-reset world.

That's the calculation with perfect salt. But there are other factors, first there are apparently at least two MD5 hashes, so that cuts your performance in half. Also, your dictionary is very small. You'd get the lowest of the low hanging fruit (the "kittens" users).

By comparison, if there's no salt, you just hash every entry in the dictionary, which is a function only of the dictionary size; it's independent of the number of users. Then you just the result as a lookup table, which can be done in main memory these days, and write the result out as a list of usernames and unencrypted passwords.

That would take awhile to set up, but a handful of seconds to run for a good-sized dictionary.

I reiterate: you are simply not paying attention. I don't know who you think you're arguing with, because you're obviously not reading what I wrote.

I just had another thought.

What if LL wasn't using a strong password hash? What if they went "ohshit" and then that is why they forced a large-scale password reset? They blew off the current weakly-hashed/"encrypted" passwords and forced people to re-enter passwords so that would force a refresh of the hashes. (Using a hastily-banged out change in the last two days.)

However strong it is, it doesn't matter. With any hash you can still get the low hanging fruit in minutes, and there's going to be lots and lots of it among half a million accounts.

Adam and I seem to tentatively agree that that's the most likely explanation, although I still have some suspicion in the "screw this, let's at least look like we're doing something decisive" direction.

But if that were the case, you would pull the plug immediately (which I guess explains the downtime Wednesday), not wait two days and still have no plan for dealing with the obvious fallout from such a reset.