BitFunder.com has been hacked and IT IS BitFunder's fault

[pikeadz]

So what it sounds like to me, a layperson, is that bitfunder has some shitty code that potentially allows for a fraudulent transfer to happen. 

OP is bitter because he and another person lost their shares due to 1) that exploit AND 2) their failure to use 2 factor authentication.  If they had used 2fa, they would still have their shares/coins.  Is that correct?

I'm not saying bitfunder shouldn't have to revamp that code.  In fact, they should fess up to this flaw and as a kind gesture, refund the coins.  But isn't this exactly the type of thing 2fa is designed to prevent?  Who in their right mind WOULDN'T enable it, especially AFTER something like this has happened to you.  (if you read the transcript, this fool didn't even enable it after the loss) 

[1715188349]

1715188349

[1715188349]

1715188349

[1715188349]

1715188349

[MPOE-PR]

Websites are not safe for this application. Learn GPG. That is all.

[nubbins]

Websites are not safe for this application. Learn GPG. That is all.

I detect many suppressed lels in this statement.

[Lohoris]

Yipes! As someone who has worked in web development for several years, this is SHOCKING.

I created an account a while ago, but never deposited any BTC because I didn't want to use WeExchange. Now I'm glad that I never!

+1

[Ukyo]

So what it sounds like to me, a layperson, is that bitfunder has some shitty code that potentially allows for a fraudulent transfer to happen. 

OP is bitter because he and another person lost their shares due to 1) that exploit AND 2) their failure to use 2 factor authentication.  If they had used 2fa, they would still have their shares/coins.  Is that correct?

I'm not saying bitfunder shouldn't have to revamp that code.  In fact, they should fess up to this flaw and as a kind gesture, refund the coins.  But isn't this exactly the type of thing 2fa is designed to prevent?  Who in their right mind WOULDN'T enable it, especially AFTER something like this has happened to you.  (if you read the transcript, this fool didn't even enable it after the loss) 

Very much agreed.

Now that BitFunder and WeExchange is finally getting support staff team to help offload tickets and other requests, I am now able to spend more time focusing on operations including the legalization of BitFunder, and hiring additional developers and even multi-lingual support staff.

We have already began conducting a full code review and started on a backend systems redesign with lots of new features and most importantly, security in mind.

-Ukyo

[Lastro]

(if you read the transcript, this fool didn't even enable it after the loss) 

Is he a fool? His account was cleaned out.

Very much agreed.

What are you agreeing too Ukyo? A refund to the op?

[Ukyo]

(if you read the transcript, this fool didn't even enable it after the loss) 

Is he a fool? His account was cleaned out.

Very much agreed.

What are you agreeing too Ukyo? A refund to the op?

He was calling him a fool because after the cleanout, the user still refused to enable 2factor.

I am agreeing to a code revamp and update with more enhanced security options and features which we started a few weeks ago when this problem with transfers was fixed requiring google 2-factor authentication. Without 2-factor, anyone can claim "I was hacked! It was a bad website, it was a trojan, a virus loaded pages and grabbed a per-page generated code and did everything!"
Unfortunately there is so much fraud and so many fraudsters when it comes to bitcoin, that we cannot accept that as an answer since there is no proof otherwise.
This is why we have adopted the 2-factor requirement. We are looking to add additional options such as optional pins (That can easily be recorded one time by a trojan though), yubikeys, and other new technologies.

-Ukyo

[muasktak10]

This comment isn't really beneficial to the conversation.... but no wonder the price of btc is tanking.

[EskimoBob]

You are using Googles 2-step verification and this requires a phone that supports it.
What if I do not have nor like those huge shiny slabs of glass and plastic, every fashion victim drags around so happily - drooling, while finger fucking his/her phone every waking moment.

mtGox sent me a yubikey for free I know, you probably can not do this right now but there has to be a way to fix those security issues by not forcing your clients to depend on some third party crap from Google. Especially from Google.

Even PIN provides some level of protection, when every failed attempt causes n+1 seconds delay. Add a letter to 4 digit PIN and it got way better.

[ninjaboon]

You are using Googles 2-step verification and this requires a phone that supports it.
What if I do not have nor like those huge shiny slabs of glass and plastic, every fashion victim drags around so happily - drooling, while finger fucking his/her phone every waking moment.

mtGox sent me a yubikey for free I know, you probably can not do this right now but there has to be a way to fix those security issues by not forcing your clients to depend on some third party crap from Google. Especially from Google.

Even PIN provides some level of protection, when every failed attempt causes n+1 seconds delay. Add a letter to 4 digit PIN and it got way better.

I also have a free yubikey from Mt.Gox but not many sites support it.
So I'm forced to use Google 2FA and I have it installed on 3 devices for backup purposes.

[🏰 TradeFortress 🏰]

Just use one of the web g 2fas.

[davout]

You are using Googles 2-step verification and this requires a phone that supports it.
What if I do not have nor like those huge shiny slabs of glass and plastic, every fashion victim drags around so happily - drooling, while finger fucking his/her phone every waking moment.

mtGox sent me a yubikey for free I know, you probably can not do this right now but there has to be a way to fix those security issues by not forcing your clients to depend on some third party crap from Google. Especially from Google.

Even PIN provides some level of protection, when every failed attempt causes n+1 seconds delay. Add a letter to 4 digit PIN and it got way better.

Google Auth is an implementation of a open standards called TOTP and HOTP that you can use on a regular computer (or theoretically with a watch, a pen and a paper). Hurr'durr'ing is hardly justified here.

I also have a free yubikey from Mt.Gox but not many sites support it.

No other site than mtgox itself can support the Yubikey they send you. If you see a site claiming that they support gox's keys too you should run.
The reason is that a yubikey contains an AES key that is used to generate and validate OTPs, with a regular key you can validate OTPs against the Yubico servers since the AES key is filled in by Yubico itself. At mtgox they flash the keys and replace them with AES keys they only know, making the key effectively unusable anywhere else than at gox itself.

[EskimoBob]

Can you generate PIN's that can be used only once? Question is, how to deliver the list of keys to your client so you "they" (bad guys) not have them
  

Code:

1)  11975
2)  14975
3)  07277
4)  06680
5)  14321
6)  28753
7)  90415
8)  91468
9)  99442
10) 95016
... 

None of the numbers can be reused. When I log in and start a transfer or any other operation, where coin/shares move, system ask for a PIN #?. Lets sat I have used 1-3 so it asks for PIN 4 and then for #5 etc.
If I screw up and enter PIN #4 incorrectly, PIN #5 will be asked and so on.
If you add a delay, that starts to grow after every wrong entry, brute force becomes pointless. Even better, lock the account down after 5 wrong PIN entries and send out an e-mail.

[nubbins]

blockchain.info's SMS verification is similar to what you're describing. The login page sends you a one-time code via SMS that you must enter into the browser, along with username and password.

For a trivial amount of effort, you could extend this to any sensitive action: sell, transfer, etc. No yubikey or even smartphone required, just a phone that can receive SMS. The security-minded could purchase a cheap prepaid mobile phone for this purpose, and keep it in a secure location.

I'm not sure of the cost related to sending out that many SMS messages, but that's not an insurmountable problem.

[Lohoris]

blockchain.info's SMS verification is similar to what you're describing. The login page sends you a one-time code via SMS that you must enter into the browser, along with username and password.

For a trivial amount of effort, you could extend this to any sensitive action: sell, transfer, etc. No yubikey or even smartphone required, just a phone that can receive SMS. The security-minded could purchase a cheap prepaid mobile phone for this purpose, and keep it in a secure location.

I'm not sure of the cost related to sending out that many SMS messages, but that's not an insurmountable problem.

very good observation.

the cost of sending many SMS is quite low if you buy them in bulk, so as long as you have *any* profit, that would be fine.

[nubbins]

Moderate increase in tx fees for those who have SMS verification enabled, say.

It might not make economical sense for smaller trades, but the trading bots don't have mobile phones, so there's no big worry there. 

[Ukyo]

I agree that there need to be more options than just 2-factor.

I have been talking with Yubikey about some alternative solutions, even for mobile access  as well as working on a big and controversial id verification method that will be optional as well.

Thanks,
Ukyo

[prof7bit]

So, I can use google 2-factor without a phone ?

The wikipedia page about it http://en.wikipedia.org/wiki/Google_Authenticator lists a whole bunch of alternative implementations, including ones for Windows (or Linux or Mac) desktops as well as the **trivial** 10 lines of code that describe the algorithm, so you could probably even implement it yourself in a few lines of any scripting language. A phone is really not needed to run this extremely simple code.

[Entropy-uc]

(if you read the transcript, this fool didn't even enable it after the loss)  

Is he a fool? His account was cleaned out.

Very much agreed.

What are you agreeing too Ukyo? A refund to the op?

He was calling him a fool because after the cleanout, the user still refused to enable 2factor.

I am agreeing to a code revamp and update with more enhanced security options and features which we started a few weeks ago when this problem with transfers was fixed requiring google 2-factor authentication. Without 2-factor, anyone can claim "I was hacked! It was a bad website, it was a trojan, a virus loaded pages and grabbed a per-page generated code and did everything!"
Unfortunately there is so much fraud and so many fraudsters when it comes to bitcoin, that we cannot accept that as an answer since there is no proof otherwise.
This is why we have adopted the 2-factor requirement. We are looking to add additional options such as optional pins (That can easily be recorded one time by a trojan though), yubikeys, and other new technologies.

-Ukyo

Am I the only one finding your excuse for not refunding victims here a little disingenuous?

The 'htemp' hack has been documented by many people, and the root cause was a clear defect in your security model.  But you won't own up to the failure because somebody might pretend to be hacked?  You have a clear trail for anyone who had funds transferred to the 'htemp' account.

I don't see how you can justify not compensating victims in this case.  Considering the huge fees you are collecting on trades you should take a day's income and make your mistake right for the victims.  If you want to require 2FA for compensation in the future, that is a different matter.

[Ukyo]

Am I the only one finding your excuse for not refunding victims here a little disingenuous?

The 'htemp' hack has been documented by many people, and the root cause was a clear defect in your security model.  But you won't own up to the failure because somebody might pretend to be hacked?  You have a clear trail for anyone who had funds transferred to the 'htemp' account.

I don't see how you can justify not compensating victims in this case.  Considering the huge fees you are collecting on trades you should take a day's income and make your mistake right for the victims.  If you want to require 2FA for compensation in the future, that is a different matter.

The issue was not from a cross-site post, but from a list of user/passwords that were used by an abuser.

There was a cross-site vulnerability which has now been fixed. (https://bitcointalk.org/index.php?topic=130117.msg2685210#msg2685210)

The users effected by 'htemp' and 2 other user accounts had their accounts directly accessed by a 3rd party on first attempt who were testing a user/pass list which looks to be stolen from another site.

There was only 2 reported incidents of any account hacking via cross-site scripting, which were indeed credited.
Since the 2-factor requirement for transfers have been in place, there have been no further reports of abuse.

I suggest using a different e-mail/password combination on different bitcoin based sites out there, as you never know who else out there get's hacked and they never tell you.

Our system logged a botnet of over 5,000 account attempts one after another. The majority of the matching ones had 2-factor enabled which stopped their account loss.
Those known users were already contacted weeks ago to let them know of the situation and their vulnerability and that the should change that password combination on other sites.

-Ukyo