A small relief..

A credit card number is a 16 digit decimal number, so any number up to 9999 9999 9999 9999.

Add the CVV2 code, and that's another 3 decimal digits, 9999999999999999999 for a total of 19.

That's a 64 bit number. Now consider that LL also added "salt" (ie, extra, secret information) to the hashes. Suppose they added 128 bits of salt (which is fairly standard but I would think probably bit low for this application). That's 192 bits.

Assuming the hackers can calculate 10000 hashes per second, it would still take them more than 100 million years to try every single possible combination of 192 bits.

Of course the Lindens could have decided that, since it's credit card data, they'll go nuts and use a 1024 bit salt. If they did that, the number of years it would take to try every combination is a number with around 316 digits.

But what if the salt leaked too? In that case, they'd just need to try all valid credit card numbers. All 9999999999999999999 of them. Which at 10000 a second, finishes in much less time.. a mere 31 million years.

(No, I didn't initially believe that either, but 365 * 24 * 60 * 60 = 31536000 seconds in a year; * 10000 = 315360000000 hashes in a year; 9999999999999999999 / 315360000000 = 31709791 years to cover the space)

Now of course, this does not mean they certainly won't find anyone's card number - that's only the time it'd take to try every combination, but if they do find one they can stop looking. But it's made me relax a bit at least.

These logical posts explaining the harsh realities must stop or there will be no reason to moan for some

Modern hardware can generate 10,000,000+ hashes per CPU core, per second, not 10,000. Dedicated hackers use botnets to speed things up even more than that.

Credit card numbers, while 16 digits, follow a very specific set of rules. The first number is one of 4 values (3, 4, 5, or 6), the first 6 numbers form a restricted range that identifies the bank, and the final digit can be easily computer from the first 15. That leaves 9 "free range" digits, or just under 1,000,000,000 possibilities to search.

All evidence is that LL uses 32 bits of salt. The specific salt for a given hash is known because it is a plaintext part of the final hash.

That means that if a determined hacker used your personal information to find you, watched you go into your bank, looked up your bank's code, and proceeded to compute all the possible values for your card number, it could take as little as 100 seconds to find.

Alternatively, if the hacker had a list of all of the few thousand bank codes (not easy to obtain, but hardly impossible), it would take, say, 500,000 seconds (just under 6 days with one CPU core, maybe 90 minutes with a botnet of a hundred) to try all combinations against a single salt. (Hopefully a single salt equals a single user.)

There is some good news. LL, like all merchants, is absolutely forbidden from storing the CVV codes by their merchant agreement with Visa/MC/Amex.

Pessimists are definately welcomed to its good to have all the facts

pwned by facts and technology

I do not consider myself a pessimist. I consider the likelihood of what I described actually happening to be vanishingly small.

I think it will ultimately be found that the attackers got a fairly small amount of information, nothing near the whole database, and what they got may or may not have contained the most sensitive information. I think it will be shown that Linden massively overreacted (which is not necessarily bad, but it could have been handled better) and that they may have cut a few corners in the security system design.

My (optimistic) hope is that this incident will ultimately affect a handful of people, if any, and that Linden will use it as a wake-up call to revisit their security practices.

It was my attempt at a bit of humor , i dont think for one minute you really are a pessimist and i totally agree with what u say, lessons have to be seen to being learnt and new operational procs put in place

Common sense would say that this part of the plaintext is removed when it's being used for security, surely?

So what if the hacker has a known CC number off the list before they even start?

Sure, I just didn't want people to use my post as justification for predicting the end of the world.



If you do that, then the attacker cannot reproduce the hash. But neither can you, rendering it completely useless. So yes, the salt is always right next to the computed hash, if not tacked directly onto it.



Assuming the list is properly salted, that's only helpful in the case where the algorithm is not known but can be easily reconstructed. In this case, the algorithm is believed to be known.

Not if it's an internal database like this one - the database can have a single salt for all records, and all applications authorised to use the database can have that salt programmed into them as a constant. Of course you can have a variable salt as well to make it hard to apply things to different records. I think this is how most secure network vendors in SL work so I would hope LL would do it as well!

The credit card numbers are a concern to be sure, but identity theft does not need card numbers to flourish.

The personal info being released is enough to make someone be very very concerned.

That is, by definition, not a salt. It's a constant.

The technobabble is beginning to make my head swim.

But I guess I'm glad somebody understands this stuff.

Ah, my terminology is getting mixed up So a salt means a nonce? Or something else? And is there a neat term for an, um, "confounding constant"? And were LL using one?

Yeah, a nonce (as used by LSL in llMD5String) is the same as a salt. Its definition would be a factor that causes two hashes of the same base password to turn out differently, but in a repeatable way (hence the need to include it as part of the result).

There's no evidence I've seen to suggest that LL was using a "confounding constant" (I like that term!) or indeed anything more complicated than the exact algorithm used by llMD5String().

On second thought, that's a matter of perspective. I suppose you could count the : they insert between the plaintext and the nonce as one.

Your "confounding constant" would be one of a number of ways of adding complexity to the hash algorithm itself. I don't think there's a special term for it, or at least not until now.

One of the unexpected results of this whole mess is that I will never look at a salt shaker the same way again.

Totally.

As a processor of credit card information myself in first life (I own a business) I can tell you that having someone's credit card number isn't that terribly useful.

- Biggest risk is for a charge from a foreign country that has little in the way of credit card fraud protection.

- But your credit card company is likely to disallow this from the get-go, depending where the charge is made from. Especially in high dollar amounts.



Considering a US or other first world country scam, this is what happens:

1) the scammer hits a number of credit cards for a small amount, say 15 USD.

There is a total dollar figure (I believe 400 USD? not precisely sure) over which the crime becomes 'grand theft' and severe criminal penalties kick in, if caught.

2) It's easy to see who charged you.

To charge a credit card, you need a merchant bank account and have to be registered with a company like Verisign. Maybe the exact charging individual can't be pinpointed exactly, but whomever is paying for those financial services is in deep dog doo if there is criminal activity.



My business credit card was scammed once - a card that has ONLY been used for 'standard' online purchases like amazon.com.

And a card that has never been on file anywhere save for 'one time entry' transactions. It was scammed for about 15 USD on the last day that particular card was valid. I didn't recognise the charge, so I googled the listed charger's company name.

The charging company was reported by many people on this site: http://www.ripoffreport.com/ - located in the southeast United States. Faced with this evidence in a phone call, my credit card company immediately reversed charges and took the loss.



So my point: if you use a credit card at ALL, your risk is perhaps a lot higher than you think. You are trusting every single person with access to every database you have ever touched with that card. First life, online, it doesn't matter.

That waiter you just gave your credit card to - guess what? He's making near minimum wage and has access to the restaurant's credit card machine. And is too young to know better than to double-charge your card and pull 150 USD from the register. This kind of thing is so prevalent that many businesses disallow two consecutive charges from the same card.

They can generate 10k numbers a minute, that's great... but the only way to know which numbers are valid is to actually try to use them. Which takes much longer, and leads to them getting caught.