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

May I remind everyone of the following quote from Bitcoinica's blogspot page:


As far as I can see, other than username, email, and transaction history, none of the information you are supplying on the claims form is had by the cracker(s). I agree that asking for the password would have been a good idea, since it would theoretically take the idiots that stole the database a while to recover them, assuming the users didn't use dictionary passwords or the like.

People with weak passwords had weak passwords before the hack.

How about doing what Mt.Gox did?  If, when you enter your password at the claim stage and analyser detects it is "weak", you get put in the "needs far more strenuous verfication" pile.  For those of us with strong passwords, why are we being punished for the weak passwords of others?

I also think you trivialise how hard "reproducing your hash" is.  I don't think you know what salting is for either.  The salt could be written in giant letters on Bitcoinica's front page and it would make no difference.  The job of a salt is not be to be a secret, it is to ensure that the hash for user A is different from the hash for user B even if the passwords the users pick are the same.  It's common to write the salt in an unhashed form along with the password hash into the database.  Ideally, it is a random number selected at the time of password selection.

Given that it's not a secret, it really doesn't matter if the attacker knows it or not.  It doesn't change the difficulty of the brute forcing; it simply makes rainbow tables useless.


That is nothing to do with the Bitcoinica hack then, is it?  So certainly shouldn't form part of Bitcoinica's claim policy.


I'm glad you've shifted over to my point of view on this.  As I said earlier: the only thing potentially able to identify me securely is my password; and that is the one thing the claim form doesn't ask for.

BTW, where is the mass leak or the "hackers" are just FUDging with us ?

From hash and salt, they can brute-force a collision if you don't have a secure enough password. This is why I said "reproduce your hash" before or something to that effect.

This point applies to many of your bullet points.

Rest assured many people don't have secure passwords, and they need a procedure for everybody.



They don't necessarily need to compare it to anything. They force you to give something that a hacker cannot give, and they can compare it to your bank account when they reimburse you. They can spot fishy stuff too, like the IPs you connect to. For instance if you connect from Russia often and your name is John Smith and have a phone from AT&T they may ask you about that.



You do understand that they shouldn't use the same salt again now right? and that if they don't, they cannot compare hashes. Also, as above.



You do understand how a salted hash works, right? You understand that they won't reuse the hash and that bad passwords can be bruteforced, right? which is probably what they're doing now.

All the arguments circle around this.



Your email may be compromised since long ago. Obviously if you already are well secured then no problem, but periodically changing passwords does reduce the chances of an opportunistic intrusion.


As for suggestions like asking for the latest transfer etc... pointless, the hackers have all that. They know all the wallet addresses, they can even just look up the blockchain now, even if they didn't get this info from the database.

The policies do suggest that the hackers may realistically have the passwords, though. Rendering all these points completely moot.

Possibly however one would "hope" the site has daily backups and uses a database which has transaction logs and rollbacks.

Obviously the admin team needs to verify the database is intact and valid otherwise any validation based on the database will fail.

Still lets think about this for a second.  Lets assume the attacker did have complete access to the database.

password (hashed) means attacker doesn't know the password.  So the only way the attacker can spoof verification is if he CHANGED that password.

Name, address, other contact info is stored in the database UNHASHED.  Attacker doesn't need to modify it.  He "could" spoof verification with mere access to that data.

I have to chime in when you are talking about these minute amounts.

Funnily enough the only money I had in bitcoinica was the $1 bonus

I sure as hell won't fill in some form that could go to the hackers again and compromise my info for 0.2 BTC.

I am just watching from the sidelines here in this thread because it impacts BTC and the price ( seems to have gone way up since the shorting at bitcoinica ).

If that was to me: Go fuck yourself.

I'm not missing 1 BTC. I don't gamble my money. I gave, as in passed the ownership of, 1 BTC to someone else to introduce him to Bitcoin. He decided to try Bitcoinica on his own will. Now if he wants his BTC back he has to follow a flawed claim process...
One more person who will probably just write off Bitcoin as valid because of a Bitcoinica fuck up.

I will even give him one more BTC if he wishes me to do so. Bitcoinica can keep the 1 BTC. They sure need it more than me or him anyway.

hacker could have modified the hashed password?

It's the same claim form for everyone, so how does individual balance matter?  What exactly is the threshold of loss before you will allow us to speak?

The problem is not what it requires us to send; it is that all the information it asks for would be available to someone who compromised the database.  Therefore none of it is relevant.

The only thing actually being verified is ownership of email.

The claim form looks simple enough to me. It doesn't require you to send anything in. It gives you the option to if you want. If you are missing 1 BTC only, shut up.

Even though I am involved (in a minor way), I am in complete agreement with you.

I cannot think of a single way in which this incident would be better for me personally if the government were involved.  Does anyone think that they would get their money faster if the regulators had descended?

Yup, and every BTC business will either learn and improve, or they will die... isn't it great!  

How?  I don't think you have thought this through.

That way they wouldn't have an excuse to ask for scans of ID's to the persons who didn't send one previously.

This whole matter stinks...

I gave 1 BTC to a friend and he went along and played with it a little at Bitcoinica. Now he'll have to fill that ridiculous claim from and send them scans to get his BTC back?
Great introduction to Bitcoin he had, no doubt.

Not being personally involved in this debacle and just sitting on the sidelines watching the train wreck unfold I have to say it's just magnificent to watch a market being regulated strictly by market consumers(i.e. a free market) doing it's work. There's not a chance in the world any crony government agency would ever be this vicious in justifiably criticizing a business and it's practices.  

As I've moaned so much, here is what they should have done given the situation:

• Send an email to the registered account emails.
• The email contains a URL that is unique to that email and Bitcoinica account.  This URL is not secret information.
• The URL takes you to a page where you must enter your Bitcoinica password.  It doesn't require your username, because the URL used to access it was unique to your email which is unique to your account
• Only the true owner of the account knows their password; and only the recipient of the email knows what account the URL is accessing.  (This makes interception of the URL useless)
• Claim finished.  The owner of the email is the owner of the account.

This process works even if the database were public knowledge under the assumption that strong passwords were used (and if you weren't using a strong password, well you're in trouble -- Bitcoinica should offer an option to notify them and provide a more thorough (ID based) verification of your identity).

It fails if the database has been altered by the attacker.  Therefore Bitcoinica should have spent the last week verifying the database against old backups.

---

Edit for additional.

For the future (and it wouldn't be a bad idea if all identity-requiring businesses did this), you should supply a field where we can upload a GPG public key that matches the email address.  Then you should send all emails encrypted to that key, but more importantly ... the owner of the address has a way of proving their identity in a way that is significantly harder to forge than a JPG of a passport.

Those of us familiar with GPG would right now have our identities verified.  Those not familiar with GPG would have a distinct incentive to become familiar.

Emails are passed through multiple systems.  If any one of those systems has a dodgy admin, or has been compromised (and this whole debacle shows us that that is certainly not outside the realms of possibility) they can get a copy of your claim ID.

People are far too trusting of email.  What if there is a dodgy employee at google?  Or at hotmail?  If your emails are not encrypted, you must assume they can be read.

If the claim ID isn't confidential and doesn't gain an attacker anything, fine; but then why say it is?

I'm being particularly paranoid to make a point: far too little care and thought has been put into security at Bitcoinica.  This claims process is highlighting, for me, that still not enough is being put in.  To make up for that carelessness, I'm supposed to willingly hand over a copy of my government ID?  Perhaps if I had a little more demonstration that my trust in doing that would not be unwise (and so far it doesn't seem so).

What?  They don't need my password literally.  They have my password hash, which even someone with a copy of the database can't turn into the actual password.  Therefore to verify I am who I say I am, I supply my password (just like when I logged in normally), it is then hashed and compared with what is in the database.  This is the only piece of information that the hacker with a copy of the database cannot supply.  Therefore every other request on the claim form is validating only that I am either (a) the genuine owner or (b) someone who had access to the database.  Since that (b) group is no longer limited to "Bitcoinica Staff", it should be considered untrustworthy.


Since I didn't give them my phone and real name, what are they going to compare it against?  If I had given them, the hacker would have them too.


The hacker can supply anything he wants; since I didn't give them, there is no way to verify that anything supplied on the claim form really is from me.  In fact, all this does is open up a hole for a hacker to put somebody else's name on my account.

I do accept that if my name and phone number were already in their database, then my providing ID would (probably) prove me the owner.  Given that it isn't though, provision of an ID would not prove anything.


Obviously that's what I did.  I'm not a moron.  My complaint is that it's hardly "exact" is it?  It also makes it harder for an automated system to compare the claim against the database.  Meaning more manual work than is necessary.  Without guidance, I don't know if the automated system is going to look for EXACTly the rounded version, or EXACTLY the truncated version.  When that fails, that adds more manual work for them, and more delay to my access.  Why couldn't they just say that, or better yet, make the computer do the computer work of rounding/truncating and simply accept whatever I enter in the field?


As above, it's perfectly possible to verify that I know the password given they know just the hash.  How do you think the login system has been working?  The reason I added "possibly" is because there was nothing to stop the attacker altering the site code to store the unhashed password as well for everyone that subsequently logged in.  We can only hope that the breach didn't last long enough for that to happen.


You've raised this point again.  I'm not sure you understand how a hashed password system works.  The attacker only has the password hash, not the password.  There is no way to go from that compromised hash to the password.  Therefore the attacker cannot supply any phrase that, when hashed, produces the database hash.  I can, because I know my password.  That is how they can tell me apart from the hacker.  That is the only way they can tell me apart from the hacker -- so why ask for any of the other information?

As I said: the account email was already verified when I registered.  Other than checking that I still own it (and they were happy I did a week ago), what purpose does verification serve?  Either the email in the database is untouched, in which case it's still as valid as it was last week; or the hacker altered it, in which case the verification doesn't prove anything.

One would hope that the first thing they did was compare the database at time of compromise with a recent backup.  That will tell them whether the emails have been tampered with.  If they haven't then the emails are valid and don't need verifying.


Again: every other person who might want my money doesn't know my password.  Just as when the site or any site is live: that is the only thing that stands between them and my money.  Given that all the other information is most likely compromised, it proves my identity not one bit.  Hence, it's "security theatre".


Email ownership was already proved.  Proving it again has just given another chance at catching an unencrypted email to attackers.

Why would changing the email password help?  If it's secure already, it's fine. Why would doing it before the claim help, is the claim process going to publicly release my email?   Mindlessly changing passwords, is just more security theatre.

What's up with the CONFIDENTIAL claim IDs being send in plain-text via email?

You are wrong. If they asked for the password and then hashed it and compared to the one in the database, the hacker would have NO WAY in replicating this. That's what hashing is for. The whole security of the claim page, as realnowhereman pointed out, relies on the email address, which is very bad.