Topic: BTC-E.COM NICE RECOVERY FROM THE HACK! =) - page 2. (Read 51047 times)

It seems more like a Man-in-the-Middle attack, there would have been sniffing involved in uncovering the secret keys. It is also possible that a simple XSS "Cross-Site-Scripting" vulnerability been involved in revealing the secrets "it could be the account number field ".

Got mine back and returned theirs. I was told the USD was faked.

All of this, especially the bolded part.

I think it should be pretty obvious that nobody bruteforced sha-256 or the key, you are overcomplicating - there are so many ways the password can be leaked and so few ways it could be cracked, that I'd bet my car against a beer on chances of crack vs leak  

In most of these API implementations, they key is checked by an endpoint, and in some badly written systems it stores the key for verification directly in code or config files, which in some badly managed systems can be seen by developers or god knows who while in transit. Even if they key only exists on production servers where only trusted admin has access to, who can be sure that their cheap hosting company (interserver) which does backups for them does proper encryption?

All in all, if site operators really believe in what they posted, then it's a good enough reason to never put any BTC on that exchange, as they obviously don't understand what happened. Or lied. Or both

PS but at least they handled the situation well. Better than most other victims of the bitcoin economy

I got contacted by support, I created a new account and they returned the BTC balance I deposited yesterday so I did not lose any money.

they said they will process all BTC deposits and all trades were rolled-back already.

Having trouble buying this.

I created an account after the BTC-E went crazy, but before it was announced that it was a hack.

I deposited about 40 BTC, this morning my account does not exist anymore. I contacted the support email address, but I have not gotten a reply. I hope they took a backup before resetting the database...

In any case, I was fully aware of the fact that I was taking a risk and 40 BTC was as much as I can afford to lose right now.

I hope they will at least honour the 40 BTC deposit. I highly doubt they will honour the sells at the high price yesterday.

Assuming one hundred trillion guesses per second it would still take 1.54 hundred thousand centuries.

Given this was an API key and not an offline attack: Assuming one thousand guesses per second (which is still *crazy* generous for an online attack) that is 15.41 thousand trillion centuries.

Those numbers are for a 100% search, so even halving them doesn't look very good...

You are correct. If you know a certain password can be found within 2^n combinations you only need to try 2^n combinations to be sure to find it (and 2^(n-1) combinations to have a 50% probability).

I was thinking of a pre-image attack. 2^n tries to have a 50% probability applies to a pre-image attack on a hash function (trying to find out what data hashes to a certain value). For example when searching for vanity Bitcoin addresses.

What hash are you thinking about? I thought it was an API key. The only one who might hash this is the LR server.

This isn't the case. Only if a hash function of n-bit entropy requires fewer than 2^(n/2) tries, on average, to find a collision is it considered broken.

For example, before the MD5 hash function was broken, an MD5 collision could be found with a 50% probability by searching through 2^64 combinations. This wasn't impossible to do, and if someone had done it MD5 wouldn't be considered broken.

I could even get extremely lucky and find a collision for SHA-256. But that wouldn't matter unless I could consistently find them trying less than 2^128 combinations, on average.

this is correct.

Shouldn't that be 2^(N-1). ? In this case, 2^79 tries gives equal odds of finding the key.

the "you only need to try 2^40 before you have 50% of finding it for  2^80 password" is indeed wrong.
anything < 2^128 is considered theoretically possible and this is this is correct.

and again the attacker does not have to try this against lr's servers, once you have access to the hash you can do the attack in an offline manner, with the limit to how many hashes you an compute only being limited by your computing power.

and a hash function that has had a single collision found is considered cryptographically broken. so that is correct as well.

You need to specify which attack you are talking about in order to claim that the "security" of a hash function is so-and-so. For a collision attack - finding two messages that hash to the same value - 2^128 attempts is required (to have a 50% possibility of finding it) for a 256-bit hash function. But in order to find which message hashes to a certain hash you need to try 2^256 combinations (for a 50% probability of succeeding).

Also, if a password has 2^80 combinations you need to try 2^80 combinations in order to have a 50% probability of finding the correct password, not 2^40.

Uh no.

Also 80 bits of entropy can be computationally infeasible even with a planetary sized super computer.  Hell an 8 digit password can be made computationally infeasible.  You seem to forget that brute force is based on keyspace ..... AND .... throughput.

What if you can only attempt 100 passwords per second?

No.

+1 

YAY! Got my coins back!!
Thanks BTC-e!!

Bitcoin withdrawal is working now.

Thank you BTC-E, this matter has been handled well. I will continue trading on your platform.

according to some quick calculation, a password that uses a 62 characters big alphabet, and is 16 characters long has a maximum theoretical security of 2^80 (this figure is only a very poor estimation)you dont actually need to try all 2^80. you only need to go through 2^40 before you have 50% chance of hitting it. the attacker would compute this offline.2^80 requires a non trivial amount of work but anything below 2^128 is considered theoretically possible.

as far as i can tell from some 2 minute skimming through what is public available on lr's site about their api, they use sha-256.

a 256 bit hash function gives a maximum theoretical security of 2^128. 128 bits is considered out of reach for any sort of brute forcing for the foreseeable future even if all of humanity colluded to do it, so the problem must lie somewhere else if they indeed use sha-256, unless whoever is responsible for the breach has access to a new,undisclosed,unpublished,unknown to the public cryptographical attack on sha-256. this is not likely to be the case. the sha-2 hash function family (of which sha-256 is a part of) is considered state of the art, and a new, real-world practical attack would be MAJOR news and would have very big implications.

so another, more likely possibility is that btc-e did not handle their api key properly (someone from their staff disclosed it, they spilled it out somehow, etc)

another possibility is that they did not generate the api key properly (not random enough, maybe they used a third party to generate it and this third party was malicious or was compromised, maybe the third party also didnt generate it properly, etc.)

it could also be the case is that they are not telling us the entire story, or maybe they didnt use a key that strong.

there is also always the possibility that the api itself is flawed (maybe they used a old version of the api which lr had already replaced but left in anyway for legacy purposes?)

if they used any cryptographically weak hash function, or a hash function that is any shorter than 2^256 it is possible that their key got compromised that way but cryptography is almost never the weakest link.

If there were many small companies, insurance may work by gathering more on average than they pay out.