Topic: [Emergency ANN] Bitcoinica site is taken offline for security investigation - page 30. (Read 224563 times)

Especially when we consider the question of the open positions and at what price they will be liquidated. If the market makes a sharp move in any direction this can get real ugly real fast.

Yeah that would be the common attack vector.

Generally speaking there are three ways to guess a password.
a) precompiled lists of likely passwords (often 5-8 million based on prior large scale breaches - people love re-using passwords even after breaches)
b) base word dictionary (also contains slang, names, famous people, brands, etc) combined with exhausted or heuristic substitution
c) pure brute force.

The order in which a cracker will use the masks is kinda an art-form.  Some choices are obvious, some choices are more subjective.

There are only 857K total 1 to 3 char passwords so they are often checked first.
Next try your "common password list".
A 4 char brute force usually makes the most sense (81 million).
Around 5 or 6 char brute force starts to not make much sense.  That assumes you are going against something solid like bcrypt.
So usually after 4 or 5 char brute force trying base word + substitution/prefix/suffix makes more sense.

If a site puts restriction on min or max length or invalid char that narrows down the search range.   

Back to the question of WHEN WILL WE SEE THE FIRST FUNDS BACK TO THE CUSTOMERS? This timing may well lead to more volatility of bitcoin trading and to know this date would be very much appreciated.

Thanks, very informative.

Sorry to derail the thread with this (not that it's anywhere near the tracks anyway), but I'm genuinely interested. For the above numbers, that would be for a single salted password assuming a dictionary attack fails. The average expected time to crack such a password would be 3.5days, but probably less if they prioritized on common alphabet letters (ie, lowercase e vs uppercase Q). Would the expected attack vector in that case be to use the known work size and then go through each user and their unique salt first using dictionary word, then working out from the minimum password size exhausting successively 4 character passwords, then 5, 6, etc?

If my napkin calculations are right, given the above numbers and assuming 10k users, they would discover all the dictionary passwords fairly quickly (a couple days for a 1 million entry dictionary?), then 10k users * (53^4/(36000*60*60*24*2)) = 12.7 days to discover all the 4 character alpha passwords, a little less than 2 years to crack all the 5 letter passwords, etc. Again, average time might be less than half the full space if they focus on common letters first, but as a ballpark would those numbers make sense?

How is Google authenticator , OTP factored into this cracking time.

Or was something lost about it ?

It depends on the work-level but lets assume a work level of 10. That means a single core of server can verify a password in ~ 3 ms or 300 p/s.  A 5970 would be ~30x as fast (optimistic) so your might be getting ~ 9kp/s or 36kp/s for 4x5970 rig.

If your password can't be found in a dictionary or easy password list to brute force all 6 char passwords would require
alphabet only (53 values) 53^6 /36000 / 60 /60 /24 = 7 days
alphanumeric (63 values)  63^6 36000 / 60 /60 /24 = 20 days
printable symbols on keyboard (95 values) 95^6 /36000 / 60 /60 /24 = 236 days

If the salt is random per account that means each account must be cracked separately.

Of course the attacker could use multiple GPUs so a good way to think of it is in time value.    A single 5970 can generate ~0.5 BTC per day.  So cracking a 10 BTC account is worth ~ 20 GPU days.  Cracking a 1000 BTC account is worth ~2000 GPU days.  If it takes the attacker longer (in GPU days regardless of actual time) then it isn't worth it to try.

While 6 charecters (not on known password list, not repeated on another site, not a dictionary or common word w/ only 1 or 2 substitutions) is likely good enough.  Still adding just 1 or 2 more character significantly increases the time value cost.  A 7 char (all printable keys) password is ~ 90,000 GPU days (5970s).  The time value is worth 45,000 BTC meaning even if someone had sufficient GPU power it wouldn't make sense to attempt the attack unless the account was worth more than 45,000 BTC.  They could make more mining legit than trying to break the account.  Given the attacker has no idea if he will ever crack it (maybe your password is a purely random 14 character string "pOQs9jb!su3gp@") it doesn't really make sense to even try.

6 is likely "good enough" if your password is complex enough but 7 or 8 chars makes it so expensive the thief isn't going to even try.  In the time it takes to brute force a single 8 char password one can brute force 86,000 other accounts trying all passwords length 1 to 5.

If you have 5 million users, you should have dedicated authorization hardware.
And yes, those that use the password "password" or "abc123" deserve to be hacked, because that isn't going to stop someone with a bcrypt database and salt in hand.

D&T

Maybe I am coming from this wrong. The 'attackers' have the DB with the hashes, correct?  And they have the codebase, I would assume.

They have what they need, imo. For easy passwords.

I'm not arguing that it isn't hard, it is.

I am also not saying this is possible for a normal organization.

But there are organizations out there that can do it.

But then again, it probably wouldn't take that long to go around typing in into websites to get a hit and save all those calculations.

Lets take what we know: bcrypt is good but it has a cost to being good. The stronger a site makes it based on the number of users, the more cost there is to the site owners in calculations. Given what is known about bicoinica we could make some assumptions there. (ps. Using one's own use of bcrypt against a company is a form of financial attack by forcing the company to have more resources to calculate the logins).

Or if I had 1 person logging in the # of rounds can be high for little cost, but if I had 5 Million people logging in, then the # of rounds becomes a financial question in terms of hardware.


In anycase, whoever used the password password will have some issues claiming his probably thousands of coins from bitcoinica because there will be more than one claimant.

bcrypt has been around since 1999.  The length of time is kinda immaterial though because of Moore's law. If you started 12 years ago due to Moore's law the amount of work completed in those first 12 years would only be equal to 2 years if starting today (same budget/space/resources).

You can't ask something like "has 1 million passwords been rainbow tabled".

There are 3 inputs for bcrypt
the plain text password
the work level (# of rounds)
the salt

So even to build a rainbow table of 1 million passwords you would need to pick a work level and salt value.To have any practical value you will need multiple tables one for every salt value and work level combination.   Obviously both of those parameters are nearly infinite so you would need to select some constraint.  

Say you limited your project ot all 32 bit salts and work levels <= 20.  That means not 1 rainbow table but 80 billion rainbow tables (each containing 1 million passwords and their hash).  So you build a farm with a million or so GPU and at ~$1B or so in cost and a decade of time you have precomputed all 1 million most commonly used passwords, for all 32 bit salts, and work level <=20.  The disk space alone would be (assume 70 bytes per record) 70 * 1M * 20 * 2^32 = ~ 6000 Petabytes (6 EB).  If stored with no redundancy or backup on 2TB drives would require 3 million drives.  RAID & off site backups would more than double that.  To put that into perspective the entire human race's stored data (in all forms) is estimated at ~300 Exabytes.

Despite all that work if the website uses a >32 bit salt or work level >20 it is worthless work.  Given Moore's law is continually increasing over a long enough timeline every site will be using work level > 20 and salt > 32 bit rending your work obsolete.

If this seems hard to overcome.  That is the entire point.  By using per round salting, unique salt per user, and a modifiable work level the whole "point" of bcrypt (and other similar algorithms) was to make precomputation impossible.

Feel free to correct me on this, it's not my area of expertise. 8+ characters would be ideal, but with a good salt each password would have to be cracked individually, and the attacker would not know from the hashes they stole which ones are insecure.

Thus, with a strong salt making anything but huge rainbow tables ineffective, while some users might have relatively weak passwords that could be solved in reasonable amounts of time, the attackers wouldn't know which they are and would have to attack the entire DB looking for them. How long would it take with a reasonable GPU farm (say 4 5970s) a 6 character case sensitive Latin alphabet password?

Please don't make me waste more of my Friday afternoon over absurd arguments.

This is the post I replied to:


He says that my argument is not correct, but it is. Difficulty rises dramatically as he said, but that doesn't mean that "even the simplest" passwords cannot be bruteforced.

That's what I meant with "not really." Yes, bcrypt makes less entropy necessary, but still a decent amount of entropy is required. Trivial passwords are still beaten by dictionary attacks and brute-forcing.

I'm absolutely convinced that many Bitcoinica users have weak enough passwords such that they have been broken already, bcrypt or not. Which is why they really cannot afford to temporarily reopen the site.

This is the point, not if you can crack away 1000 bcrypt trials per second or 1E+6. Given a trivial enough password, either would do. Bitcoinica didn't enforce strong passwords, that's a fact.

2^(workfactor) if I recall correctly. FPGAs can be used successfully against BCrypt, despite it's security. Not to say BCrypt is insecure, like you said it's capable of thwarting rainbow tables and most brute-force attacks.

Scrypt is an interesting alternative though. It has a max-space factor bringing hardware costs into the equation.

Yes it isn't easy and can be expensive: If you start Now.

Let me ask: How long has bcrypt been around?  Do you think the first 1 Million Easy Passwords haven't already been tabled?

Protecting the DB is of the utmost importance, maybe more importantly, force strong passwords on registration.

An article of possible interest.

http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html  

for those of you taking notes, there is no good reason for anyone to transmit a clear-text password, strong or weak, to any web site. one is supposed to use zero-knowledge proofs for this, this also avoids possible dictionary attacks

https://en.wikipedia.org/wiki/Password_strength

Sorry to delegate on Wikipedia but I really have used way too much time in this thread.

Typical rules of thumb include using 8+ characters, mixed capitalisation and both numbers and alphabet characters. (See the entropy table in the article linked).

What's considered a short, weak password?

Well maybe you should read before you respond.

Your respond to a most that said long passwords would take years to break saying "not really" and then now say "we" (which I guess means only you) are talking about short weak passwords.  Of course it was already pointed out that  bitcoinica can determine how strong the password are so verification of accounts w/ strong passwords presents no security risk.

Sure, we're talking about short, weak passwords. Bcrypt is slow to bruteforce, doesn't mean it isn't a concern if the password isn't strong enough.

Nitpicking over the obvious here, really.

Long complex passwords simply can't be brute forced via any cryptographically secure key derivative function (like bcrypt) in any useful amount of time.  

10x sounds impressive until you realize that means "only" decades instead of centuries.  One also has to consider the value of the computing time.  Spending $10,000 in computing time to steal $500 isn't a good way to become rich.

That is the point of salt.

32 bit salt = 4 billion permutations of every password.
So to pre-compute the 1 million most commonly used passwords would require ~ 5 quadrillion operations.

bcrypt uses hundreds or thousands of rounds to hash the password.  Throughput even on high end GPU is slow for bcrypt.  While a 5970 might be able to process ~8 billion MD5 hashes per second it is in the <10,000 bcrypt (2000 round) passwords per second.

So you are talking ~ 5 quadrillion  /10,000 /60 /60 /24 /365 = 158,000 GPU years (i.e. 1x 5970 for 158,000 years or 158,000 5970s for 1 year or some combination).

Of course even if hackers were stupid enough to waste the billions of dollars that would cost all that pre-computed wealth could be erased by simply going to a 64 bit salt.