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

They don't know your password. They can't verify your password except by using the same hashing and salt again, which would be stupid since hackers could then replicate it.
So for all intents and purposes bitcoinica doesn't have your password any more.


This is why you have to verify your email. It's critical now. And that's why they need your phone and real name now without exception. And transfers would have to match it. Tough luck, they cannot reasonably go about it any other way.


Well, they need it now. See above.


Won't this be checked manually? just give your best guess man, and if you think it's accurate to the cent, choose "exact".


If they really had them hashed, they don't have them unhashed anywhere. They better not, anyway.

In your case, you didn't give them your info (good idea) but you did keep a quantity of money there (bad idea). How can they tell you apart from a hacker who has the same password info as they have? they can't. All they can do is a best effort and proof of email ownership should be enough in many cases, together with the fact that a hacker won't try and give their real info to get money out of there using the claim procedure. The rest of the "nonsense" is not to tell you apart from one of the hackers, it's to tell you apart from some other person who might want your money, other than the hackers, using stolen identities.


This sounds like a reasonable concern.


See above. Email ownership is now critical. If you have a significant amount in your account, it's probably a good moment to change your email password from a properly secured computer, before filing up the claim.

What's wrong with the claims page:

• It's not asking for the account password.  Anyone who knows the usernames (and we can assume the attacker has a copy of the database) can submit a fake claim, and at the very least delay the real claim.
• If the attacker had access to the database, how does any of the information asked for demonstrate my real identity?
• It asks for real name and phone number.  I never gave bitcoinica that information in the first place (that bit of paranoia has paid off).  No advice is on the page for people in that position.
• EXACT balances are requested, but if you supply exact balances it rejects the request saying "give only two decimal places".  It's not EXACT any more then is it?
• Rejecting EXACT balances of more than two decimal places is pretty bad; but no advice is given as to whether the two decimal places you supply should be rounded up or down from your exact balance.  If I have 10.009 BTC is that "EXACT"ly 10.01 or 10.00?
• Given that there was a complete database compromise -- exactly what is it that you're achieving with all this nonsense?  Assuming you kept the passwords hashed, then the only bit of information that can be used to verify the owner that is possibly not compromised is the real owner's knowledge of the unhashed password.
• All you are actually verifying with this circus show is the owner of the email is the one making the claim.  However...
• You send out a verification email, which has no information on it other than a URL to click.  You have to click the link to see what the verification details were; but the verification page has no "approve" or "cancel" button.  So if an attacker does submit a fake form, then they simply hope that the actual owner clicks the link.  Given the dearth of information about the process from bitcoinica, and the lack of advice in the verification email (i.e. "don't click this link if you haven't started a claim") the user will assume that this email is the start of a claims process and will click the link; giving legitimacy to the fake claim.
• My email was verified when I registered the account -- what possible purpose is there in verifying it again?
• As continued evidence that you still haven't learned your lesson... you are relying on unencrypted email (FOR THE THIRD TIME: EMAIL IS A POSTCARD) to deliver information that you specifically say "should remain confidential".  The claim ID should have been listed on the original claim page after confirmation and only half of it should have been sent in the email.
• In short, this entire process is security theatre; not actual security.

In a situation that requires ambiguities be kept to an absolute minimum (one assumes the claims system will ideally be done automatically for the bulk of the work) you've added ambiguities where there need not have been any.  "Two decimal places" especially... what, are you short of bytes?

Seriously, what exactly do you think this "claims process" is achieving or protecting.  In what way is this a security measure?  Are you simply trying to verify if the database has been tampered with?  If so, SAY THAT.  Don't doll it up as if it's some kind of security measure for our benefit.  If the database has been tampered with you can't trust it anyway, so verifying emails is pointless.

Possibly people just do not have the resources or experience to set things up properly? For instance you clearly cannot rely on even physical security of any one machine, so at a minimum we are talking about multiple machines distributed across multiple physical locations for your site. Also dont forget your custom bitcoin client. None of this is cheap, least of all people to work on it who know what they are doing. Maybe it is not worth it to spend that much just to secure a few tens of thousands of bitcoins.

I luv these geeked out security discussions after the fact .... and in the end when everything is plain sailing they go back to hiding the key under the doormat.

It's a bit worse than that, the nameservers are acting really weird. http://www.intodns.com/bitcoinica.com
I did a bit of nslookup'ing, and the DNS servers don't respond when asked for SOA, NS or A records. OpenDNS has cached copies of the A records, but not all of them, and no cached copies of NS records.

Cached dns may be causing all the troubles. They will surely work when the cached entries timeout.

this works for me.

https://173.45.224.244/

claims works fine on my chrome, www doesn't resolve ever since the incident

I was able to connect to the claims.bitcoinica.com site once in firefox, but have never been able to connect to www.bitcoinica.com. Now, I can't access it either. I'd guess the DNS is either being DDoSed, or it has a major problem with its round-robin setup.

Or Chrome.

The weird thing is that Firefox won't connect, but Internet Explorer will.

Wheres the claims page?
All I'm getting is this ....

Unable to connect
       
Firefox can't establish a connection to the server at bitcoinica.com.
       
The site could be temporarily unavailable or too busy. Try again in a few moments.
If you are unable to load any pages, check your computer's network connection.
If your computer or network is protected by a firewall or proxy, make sure  that Firefox is permitted to access the Web.

 

I can see it now!


What the hell does 01000011 01101111 01101100 01100100 00100000 01010111 01100001 01101100 01101100 01100101 01110100 mean?

This is safe now because we no longer point to the load balancer.

The domain is being controlled by a single reliable team member. Just make sure that it's https. (There's no way to get a SSL certificate without proving the domain ownership. Please do not trust any SSL certificate for bitcoinica.com issued before May 10, 2012.)

What? Is this site safe to submit a claim or not? Because after your post in the apology thread I already did.

@DnT: www points to a blogspot google IP.

-coinft.

They didn't divert a DNS record. The hacker manipulated our load balancer (which acts like a reverse proxy) to some site that I'm not supposed to access.

If they could divert a DNS record .... wouldn't that mean they could also spoof the www.bitcoinica.com page only?

How can we be sure this page is legit? No official post here, and not even a link to it on www.bitcoinica.com. I don't feel good giving this information to anyone who might be able to divert a DNS record.

-coinft

That totally looks like it needed 5 solid days of team work 

  _{Sorry... just on the wind up a bit before going to sleep.}