Topic: Camp BX Hacker / Security Audit: Results (Read 15921 times)

That's a load of BS mate. I had a withdrawal cancelled a couple of weeks before the snowstorm, and no explanation, apology, or any kind of response from your "team".

And this doesn't help your credibility either:

https://campbx.com/achupdate.php

 I can't believe you would finally post here after all the crap you've caused so many people.  I had a withdrawal, not even a big one, waiting for WEEKS and you kept saying excuse after excuse.  Finally I took my money out and will never be back and there are many others with similar stories.  Why don't you have a legit explanation about what's going on and been going on for 3 months now?

Hi Aurum,
     No we have not!

We have disabled email helpdesk to minimize spam.  You can create a ticket with helpdesk and our team will get back to you in 2 business days.  Live chat is also available from our after-hours team.

The withdrawals are backlogged by a few days due to our backend system switch and bank closures in Atlanta after the snowstorm.
We are working hard to clear the backlog.

Thank you,
     Keyur

Wow bounced e-mail from campbx?  Not a good sign

Has CampBX failed

I requested a withdrawal 9 days ago and nothing.
I submitted a support ticket and nothing.
I called and no answer.
I emailed [email protected] and it bounced.

I am happy to hear this Alex.  If MtGox gets hacked again, it can be a very big setback to Bitcoin.

Hi Stephen,
      We have been tweaking out security and monitoring procedures since launch to stay ahead of any potential issues.  I reviewed our change tracker sheet and there have been over 120 changes in 2012 (this includes everything from cosmetic edits to server hardware upgrades and patches), which should give you an idea of the work behind the scenes to stay current.  Here is the specific information you requested:

 - Does Camp BX use cold storage (an offline wallet that cannot be accessed should the exchange's service become compromised)
Absolutely.  We have hot wallet / cold wallet split system.


If so, then there are other questions:

 - Is there a target as to how much of customer's funds are kept in cold storage?  (e.g., percent of total, or perhaps relative to recent withdrawal requirements)?
Our wallet has higher churn rate, so percentage kept in hot wallet needs to be much higher than MTG's 3% number.  We set it based on current activity levels + volatility headroom.

 - Do new deposits go to cold storage?  (if the hot wallet is compromised, new deposits made (e.g., automated payouts by mining pools) would still be secure)
No - new deposits go to the hot wallet.  We have considered sending new deposits to cold wallet, but implementing and operating that code will require us to touch cold storage much more often.  This may defeat the purpose of cold storage.

 - Does the offline wallet where the cold storage resides remain protected due to an "air gap" (no access to it electronically, not connected to the network)?
Yes - air gap is a must otherwise it would be a "luke-warm wallet"! 

And I have other questions that I'ld like to now the answers to:

 - Does CampBX maintain full reserve?  (i.e., Camp BX controls bank accounts with all customer USD funds and controls wallets with 100% of BTC funds.  None of these amounts loaned out.)
Yes - for both USD and BTC. We do not lend or spend any of the funds.

 - Does CampBX maintain offsite backups of its accounts and transactions?  If for some reason the exchange's primary account database were lost due to a security breach, what information (and how recent) is still available from backup or archives?
Yes - this has been part of our DR plan since launch day.  In case of a server crash (much more likely than security breach, IMO) we can recover up to 1-hour recent data.

 - If there is a security breach and CampBX cannot meet withdrawal requests of its customers, what is the withdrawal preference that Camp BX would follow?  Various preferences are:
 - -  A.) All deposited funds are of equal standing with bitcoins being valued at their market rate at the time of the loss,
 - -  B.) Withdrawals of USD funds, if not impacted by the breach, are made available to those customers who held a USD balance. in full.
 - -  Do customer deposits have preference over any other creditor claims?  (i.e., a contract stating so such that they don't become unsecured creditors ending up in the same pool as the landlord for office space and hosting bill.)
 - -  or is there some other approach?
Answer to this question really comes down to the situation at hand.  If it was an overnight heist like what happened to MtGox or BitFloor, we may have to go for (B).  If this was a trickle-heist like MyBitcoin the answer may be more complicated.  The good news is that we do not have any creditors, so in case of a breach all funds will go back to customers.  Verified customers will get preference over unverified customers.

Hope this helps,
     Keyur

Shortly < 1 month

Hi Stephen,
     Excellent questions, and a lot of them!  I will post an update to answer these shortly.

Thank you,
      Keyur

Your service seems good but of course I am concerned with the legal reachability of a company in Japan (and the extra hassle of overseas fiat transfer).  However, its all about balancing this risk against that, so I recently got verified with MtGox.  I think "B" should be the fiat option.  Essentially, I do not want my fiat to be held as security for people who choose to leave excessive bitcoin on the exchange.  This risk makes it hard to hold funds on the exchange.

How are the paper wallets physically secured?  Hopefully they are not in an envelope in your sock drawer...

Thanks Tux, that's some clear answers

I think the "year ahead" only goes for experience, not really "technology wise", but it's still something that counts.

If you want (replaced CampBX with MtGox and replies in bold for readability):

 - Does [MtGox] use cold storage (an offline wallet that cannot be accessed should the exchange's service become compromised)

Yes.

 - Is there a target as to how much of customer's funds are kept in cold storage?  (e.g., percent of total, or perhaps relative to recent withdrawal requirements)?

On average 98% of customer bitcoins are held in cold storage, with possible variations on large bitcoin moves (large deposits or customers asking for large withdrawals).

 - Do new deposits go to cold storage?  (if the hot wallet is compromised, new deposits made (e.g., automated payouts by mining pools) would still be secure)

No, this wouldn't be practical in terms of number of bitcoin addresses to keep in cold storage. This could change thanks to BIP 0032 which we are working on implementing. It should be noted however that we are using a hardware security module for the hot wallet

 - Does the offline wallet where the cold storage resides remain protected due to an "air gap" (no access to it electronically, not connected to the network)?

Offline wallets are generated from an offline system and kept in paper format in three separate locations, using a technology based on raid. It will likely be changed to use Shamir's Secret-Sharing method in the future, and all existing offline wallets will be converted to this.

And I have other questions that I'ld like to now the answers to:

 - Does [MtGox] maintain full reserve?  (i.e., [MtGox] controls bank accounts with all customer USD funds and controls wallets with 100% of BTC funds.  None of these amounts loaned out.)

As described in our Terms of Service, customer funds are kept in full, and none are loaned.

 - Does [MtGox] maintain offsite backups of its accounts and transactions?  If for some reason the exchange's primary account database were lost due to a security breach, what information (and how recent) is still available from backup or archives?

We have realtime onsite backups on a separate system, and offsite backups at regular intervals. We are working on modifying the system to have a multi-site cluster working (working with people from Percona to reach the best system on this) - which would allow us to have a node of the cluster used to make backups way more often

 - If there is a security breach and [MtGox] cannot meet withdrawal requests of its customers, what is the withdrawal preference that [MtGox] would follow?  Various preferences are:
 - -  A.) All deposited funds are of equal standing with bitcoins being valued at their market rate at the time of the loss,
 - -  B.) Withdrawals of USD funds, if not impacted by the breach, are made available to those customers who held a USD balance. in full.
 - -  Do customer deposits have preference over any other creditor claims?  (i.e., a contract stating so such that they don't become unsecured creditors ending up in the same pool as the landlord for office space and hosting bill.)
 - -  or is there some other approach?

Fiat balances and Bitcoin balances would be accounted separately based on current rules, especially because of the difficulty to give a value to a given balance in Bitcoin (value at current rate or based on depth). This may change as we are discussing with a large insurance company in Japan to get all funds deposited on MtGox insured. This will however be only possible once the Japanese FSA provides its position on Bitcoin - which we expect to happen in the next months.

If that is the case, then how about giving the MtGox answer to the questions raised by Stephen Gornick in his post above?

I see this question (and perhaps others) is addressed in another thread -- one which I wish I had seen earlier, as that thread is the right place for this line of questioning. (if responding, please feel free to respond there)

Learning? Everyday we are learning something new... Watching? Yes very carefully... Now it is good that others start to finally work on their security... As far as we are concerned we are a year ahead of others on this matter and never stop on improving/checking things when it comes security.

These are good questions. 

Really, what is needed is a white paper describing a belt-and-suspenders approach to securing customer deposits.  CampBX has a great opportunity as the last US exchange standing and could really capitalize on that if they provided a comprehensive security document.  I really don't think such a document would help hackers much... if it did that would be an indicator that the security had issues (security through obscurity is not true security).

Additional questions:

Are these wallets encrypted?

Are there ANY unencrypted backups of the wallet, hard copies of the private key, etc?  If so how are they protected?

How are USD deposits secured?

Are USD/BTC deposits held individually and separately or is there a similar issue to bitfloor where USD on deposit could be used to pay off other losses (operating, or hacking).

(I've been a campBX user for several months now)

Thanks!

This is an old thread but there was a question asked of great importance and I don't see that it was answered:


The question specifically asks about managing an offline wallet.  The response is ambiguous and uses "wallet" singular and "it" when referring to "wallet", so that is nowhere near to being an assertion that that customer's bitcoin funds are held in cold storage.

There was a recent post pointing to the site's FAQ, but that FAQ doesn't address the use of a cold wallet either.


I wish this specific question and others had been asked of a competing U.S.-based bitcoin exchange as thousands of bitcoins would still be with their rightful owners as once they would have discovered that no cold storage was being used by that exchange things would have been different.

So, I'm submitting these questions, looking first specifically for the answer to:

 - Does Camp BX use cold storage (an offline wallet that cannot be accessed should the exchange's service become compromised)

If so, then there are other questions:

 - Is there a target as to how much of customer's funds are kept in cold storage?  (e.g., percent of total, or perhaps relative to recent withdrawal requirements)?

 - Do new deposits go to cold storage?  (if the hot wallet is compromised, new deposits made (e.g., automated payouts by mining pools) would still be secure)

 - Does the offline wallet where the cold storage resides remain protected due to an "air gap" (no access to it electronically, not connected to the network)?


And I have other questions that I'ld like to now the answers to:

 - Does CampBX maintain full reserve?  (i.e., Camp BX controls bank accounts with all customer USD funds and controls wallets with 100% of BTC funds.  None of these amounts loaned out.)

 - Does CampBX maintain offsite backups of its accounts and transactions?  If for some reason the exchange's primary account database were lost due to a security breach, what information (and how recent) is still available from backup or archives?

 - If there is a security breach and CampBX cannot meet withdrawal requests of its customers, what is the withdrawal preference that Camp BX would follow?  Various preferences are:
 - -  A.) All deposited funds are of equal standing with bitcoins being valued at their market rate at the time of the loss,
 - -  B.) Withdrawals of USD funds, if not impacted by the breach, are made available to those customers who held a USD balance. in full.
 - -  Do customer deposits have preference over any other creditor claims?  (i.e., a contract stating so such that they don't become unsecured creditors ending up in the same pool as the landlord for office space and hosting bill.)
 - -  or is there some other approach?

Camp BX got some press coverage:
http://www.zippycart.com/ecommerce-news/2796-ecommerce-solution-camp-bx-makes-bitcoin-legitimate.html
http://venturebeat.com/2011/07/07/camp-bx-bitcoin/

Also, they just announced a new affiliate program. The deal is the same as TradeHill.com, 10% off your trading fees if you sign up through an affiliate link such as this one (mine): https://CampBX.com/register.php?r=mdslj19rhcD

If you registered before the affiliate program started, email them, and they will get you the discount. (At least, they did it for me).

Their website claims they will disable your affiliate link if people complain that you are spamming it everywhere, so don't do that.

Are you planning to accommodate EU customers as well?

money went in, no problem. Now I'm just waiting to get my orders filled :-)

SELL SELL SELL! (I'm buying)

Thank you OP. It is great to see free-market certification solutions meeting the needs of customers, instead of ridiculous government laws "mandating" security.

Cheers to you, I've opened an account.

Keyur,

I have to say that I feel you have done an excellent job in responding to customer questions and issues. Far more so than any of the other exchanges, although I will say in all fairness that I think TradeHill does a decent job as well.

It's good to see that your team is taking security very seriously, and I enjoy knowing that CampBX is taking a multi-tiered approach towards security. I'm obviously biased being in the United States, but it's reassuring to see you playing by all the rules and regulations. I think you guys are positioned to do very well.

I already have some of my BTC on your site, and I will probably have more in the future.

Keep up the good work!

Jim,
     Agree with you 100% - Coming from a corporate background we consider what you mentioned essential for security.

Our servers are housed in a physically secured data-center designed to survive F3 category tornadoes (if I am not mistaken), and have connectivity with three telco backbones.  There are two Caterpillar diesel generators for extended power outages.

We have identified primary and secondary owners for Wallet, and only these two people have access to it.  
Same goes for the database.

We also background check our employees as part of the security policy, and have a matching MSA with contracting firms.


Thank you,
      Keyur

PHP/MySQL do not have any specific vulnerabilities that are not also present in comparable other languages/platforms. They are not any worse of a language/platform than any other.
That most vulnerable sites are written using PHP/MySQL, does not mean that all sites using PHP/MySQL are vulnerable. Correlation, causation, etc.

Error,
     Thank you very much for a thorough and unbiased review of the McAfee result.  We really appreciate this from you!

Wanted to add that we have a patch and upgrade schedule in place for our environment.  Admins prioritize patches based on criticality, and test / deploy them accordingly.  For majority of software we are on most recent codebase.

Thank you again,
     Keyur

It's a start, but security for a financial institution takes a whole lot more than an automated test. You need to think about things like managing an offline wallet, physical security for that wallet and for your servers, and background checks for employees. You need a non-automated inspection by an expert, who will actually take the time to look at your source code.

If you run a Bitcoin exchange and it takes off, you aren't just up against script kiddies.

Right, or to put it another way, 96% of the script-kiddie hackzorz have no shot.

I'm dubious of offerings from big corporates like MacAfee -- they might be more show than go, because there is a PR aspect for both sides (PR = lies).

Nevertheless, kudos to Camp BX for getting *some* accreditation from an objective third party.  Sure, a top-drawer hacker might still be able to waltz right in, but at least there is a real barrier to entry.  That's a lot more than some exchanges can say, and it shows that they've made a commitment to doing it right.

Thanks for reading through the report, error.

Now we should ask them about their plans for two-factor authentication, because they might not have thought about that yet...  ;-)

OK, my opinion is as follows. If you find it too long, there's a brief summary at the end. In the interest of full disclosure I must say that I signed up for Camp BX today, just like many of you, though I have yet to make any trades there.

Keyur sent me a copy of a McAfee security report dated June 30, 2011, for review. McAfee generates several types of reports after each scan. The report provided was the "Executive Report." This report states whether the site scan passed or failed and gives an explanation and summary of the results. This comprised the first four pages. The next 726 pages of the 730-page document listed all of the tests that McAfee may perform on a server, though without specific results. In short, this version of the report was designed to beat clueless CIOs over the head with and to keep the company lawyers quiet.

The results showed that the site passed scanning, with 29 severity 1 issues, and no issues of severity 2, 3, 4 or 5. An explanation within the report states that in order to maintain PCI compliance, the site must have no issues of severity 3 or higher. (Severity 1 issues are typically pointless blather; some examples I have seen elsewhere are: "Your site has a DNS server," "Your site is running Drupal" etc.)

The report provided did not give specific information as to the issues identified. This information is in a separate technical report. I asked Keyur for a copy of this report, explaining that my opinion would be limited without it. Today he contacted me and stated that he would not provide a copy of the technical report as it contains server information that he did not want to be available outside his organization, even under a confidentiality agreement. This is quite understandable.

Now for some background.

When one of these security scans identifies an issue, this is what happens. Let's say for instance that you have an SSH daemon running on your server. You almost certainly will, since this is how your administrators will make a remote connection to do normal system administration stuff. McAfee or whoever will connect to the SSH daemon and check its version, and then check the version number against known vulnerabilities. If the version number is one that's known to be vulnerable, then you get an issue. Depending on the specific vulnerability it could be anywhere from severity 2 to 5, where 2 is not very serious and 5 is fix this yesterday or you're going to be pwn3d.

So this issue pops into your next report and you have to deal with it immediately or lose your certification. In the case of the SSH daemon, the original authors of the daemon patched the issue and released a new version. Now if you were smart and bought an off the shelf Linux distribution like Red Hat Enterprise, then you are mostly guaranteed that versions of various critical software on your system won't change for the lifetime of the distribution. It will always have the specific version number of the SSH daemon (and anything else on the system). Enterprise distributions lock versions in this way to guarantee that various APIs and ABIs don't change and break the applications you deploy. So Red Hat will take the security patch from the SSH daemon, leave the rest, and give you a patched SSH daemon with the same version number, and only the security patch applied.

But this is a problem for McAfee since they really don't know you've applied such an update (known as a backported patch) unless you tell them. So one of the ways you can resolve that issue and keep your compliance is to tell them you upgraded your SSH daemon to the patched version that Red Hat provided you. The trick here is that this may or may not be true and McAfee has no way of knowing from an external scan, without actually attempting to exploit the vulnerability! I don't believe that any of the security scanning services go this far with system daemons (though they do with web app security such as SQL injection), as attempting to exploit some vulnerabilities can disrupt production servers.

TL;DR:

It appears that Camp BX is being responsible with server security. The report provided to me showed that it passed McAfee SECURE and PCI compliance. Keyur has also told me that his team responds to anything of severity 2 or higher within 72 hours. (Severity 1 "issues" typically are merely informational.) However, the external security scan services themselves have limitations, in that some of the information necessary to determine whether site services are vulnerable is self-reported rather than being scanned. This is a limitation of all such services. I can offer no informed opinion on whether Camp BX's system administrators are actually applying system updates from the operating system vendor, or on what schedule, as this information was not provided to me.

This actually took some time and a bit of work. If you found it helpful, feel free to send some BTC or fractions thereof to 15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W .

I've written some contracts there, but they are struggling with the MtGox API and it's just kind of amateur looking. I don't wanna risk a whole lot of money until the site grows up a little.

The Gods have spoken to us!  Thank you error - PMing you.

I've done PCI compliance stuff for Free Talk Live; I'd be happy to review your report in strict confidence and offer my opinion.

Thank you Keyur for such great responsiveness!
Your rate is looking great!

bitoption.org

But, if a big site that could actually get some volume going that would be awesome.

Got it!   We are at 0.55% for non-margin trades.

Thanks. I actually live in the States, but was wondering if you'd work on global scale.

Any word on your rates?

Thanks Keyur, I am aware what they offer, I talked to them at some length.   Here is their three products.  There actually aren't different tests involved between the three.
http://www.mcafeesecure.com/us/products/compare_products.jsp

Yes, you fill a questionnaire out and then the tests start.  Then the tests are the same every day.  I understand.   I am just saying to admit to what this actually is. 
 
No doubt you have logs full of tests, no one is questioning you signed up and did Mcafee Secure.  The tests in your logs will be the standard tests that the Mcafee Secure Daily PCI scan gives to every website that pays for that service.

Itsagas,
      I think there may have been couple of miscommunication on your call - McAfee has three products.  (1) McAfee Secure  (2) McAfee PCI Certification, and (3) McAfee Saas Vulnerabilities Scan.

Sales teams are not the best source for technical answers.  Please open a ticket with their support team, who will be able to tell you far more details.

Essentially, the test includes a set of probes to guess what software / versions you are running, and then the specific tests battery starts.  I have the full log available to me, and can share it with a reputed member of Bitcoin forum for independent verification.

And as I mentioned couple of messages back, McAfee is just one facet in our approach.  We are using everything from Nmap to peer-reviews to find holes before launch.

Hope this helps,
      Keyur

While it is great you have had this done, this is mostly marketing.   Unless there were some other tests done, you are being very misleading on what this really means.

Ranked #1.  When and by whom?

Really?  How were the tests specific to your platform?  To my knowledge, and after talking to them on the phone today, there is only one McAfee Secure product.  It is a standard daily PCI scan that is the same for everyone that buys that product.  You can be set up and them scanning you in hours by putting some code on your site.  As their rep said on the phone  "it is all in the cloud, you just put the code on your site and we scan every day."      

The trustmark is just a badge you get for passing all the automated tests every day.  It is a marketing "bonus" to show your customers you got the scan done, there are no additional tests involved.  They even say on their site that by displaying the badge customers got "12% increase in sales conversions"

Is this what McAfee says you have passed from using their McAfee secure product?  Or do you have other tests?  

These logos and shit are just an expensive way to demonstrate that the simple bases have been covered - something that MtGox's previous implementation would have failed to achieve, and I'm not even sure the new implementation would pass as easily as MT seems to think it would (writing your own DB abstraction layer from scratch? Really? You know the site probably would have been recovered a lot quicker if you didn't spend time reinventing the fuckin' wheel, right?). Yes, it's not anything that couldn't be checked with ./nessus - but the point is they spent the money having a third party demonstrate it, instead of saying "take our word for it".

Only a fool really thinks a "hacker safe" badge means "hacker safe", it's just an over-paid but very public way of demonstrating they probably won't fall for the dumbest of shit.

FWIW, hackers don't get into .gov boxen because of the government's weak security standards, they get into them because some asshole doesn't implement the standards correctly or completely when in practice.

Edit: ...and yes, your question about response to breaches is pertinent. My guess is, losses are not covered. To my knowledge, there are no FDIC-style things that apply to Bitcoin - ever. You probably won't have any luck finding a private insurance company who'd insure against Bitcoin losses either because of the wildly fluctuating (and potentially skyrocketing) valuation of them, and even if you could I'm sure the cost would be prohibitive for such an exchange to ever get off the ground.

I would be interested in performing a penetration test, however only with written consent.

@Serge and Ananas,
          Accepting payments from outside USA requires a lot of compliance paperwork and lawyer-time for a company, so we will work to integrate Europe payment options after our USA launch.

         Please PM me with your favorite payment options, and we will work with you to offer those options in Camp BX.

Thank you,
      Keyur

the day after the birthday of the United States.
Cool~

Thank you everyone!  We are always going to treat security as our top priority, and McAfee Secure is just one facet of our approach.  We have used multiple tools to scan for vulnerabilities, and peer-code-review sessions are already in progress. 

Someone quoted LulzSec exploits in this thread, so I wanted to point out that all of LulzSec exploits were directly from the OWASP top-10 list, and thus were preventable if there had been proper security processes in place.
http://www.pcworld.com/article/231303/lulzsec_anonymous_hacks_were_avoidable_report_says.html


We are happy to report that Camp BX is on track for July 5th launch.  We will share more details shortly.

Thank you again,
      Keyur

wish you great success.

Looks more like opportunists feeding off the Mt Gox hack. Again, this is not question about if the site can be hacked, but rather when it gets hacked, what can they do for you?

Lulsec has called it quits. If you know so much about security, where is your security firm located and whats it name? How about the security software you have released or do you just use publicly available software for you hijinks? Oh, have you a peer reviewed security paper you would like to show us ?

What is notable is that CBX is going through a security audit in a public manner. This says more about thier mind set and approach than can be said of any other btc exchange.

From campbx.com...

"Tested according to U.S. Government requirements"

I seriously doubt anyone will be impressed by that, it's more like a seal of certainty that lulzsec will breeze through the security measures in five minutes.

Fancy logos and certifications aside, any site can be hacked, what is more important is how hack attempts are dealt with from the user point of view (are losses covered?).

BTW:

Site running PHP/MySQL - Pass

GOX are you watching? Learning?

Go to campbx.com and see the countdown timer for yourself.

Keyur,

Now that you have completed your audit successfully, congratulations btw, does CBX have a tentative launch date?

I find myself very anxious to try out your service live.

Awesome work, keep it up!

Congratulations, you fell for the same ploy as Costco, Petco & friends - you're paying for a useless logo.

Correct me if I'm wrong, but iirc. McAfee only performs an automated remote scan - nothing you couldn't do yourself with Nessus or some other equivalent.

Get a proper audit done - a white/grey box pentest and a source audit. They didn't do that, did they?

I'd like to see call options.

That's awesome. May I suggest something else as well?

Put up some security bug bounties in BTC (Or maybe just offer no fees a while as the bounty?)

They wouldn't have to be massive. As places like google and mozilla have found, they'll never be able to beat what a person could get for selling an exploit package, so the rewards are kind of just token.

Very professional approach

Hopefully you will be able to do international bitcoin trading


What are your fees going to be like for the service?

good for you

Congratz. I think its apparent who the new king of the mountain is going to be. Keyur, CampBX will restore faith and confidence for many people. Best of luck to CBX.

I think I'm looking forward to this exchange. The mt gox "delay" is getting annoying. And I've always wanted the ability to put in a fill-or-kill order.

Sounds good, too bad this will be an US exchange only.

The benefit of this effort on the part of Camp BX is that it highlights just how non-transparent and less sophisticated Magical Tux and Co. are in both PR and security implementation. I have more faith in Camp BX from this posting alone than anything MT. Gox has done. You'd think they'd do something similar. But I guess that as long as people patronize them and don't force their hand, they don't have to bother - the zealots will come to their defense no matter what people point out.

These BX folks clearly understand how to market themselves, if nothing else. I'm impressed, though I'd think the BTC community could use you as a direct exchange as opposed to a brokerage.

all this really means is that the hackers will need to be a little more clever

I signed up. Looking forward to your site going live.

I agree. More openess at the exchanges would be a huge boost to confidence in bitcoin. Competing exchanges should force greater security and transparity.

Hopefully this encourages other exchanges to add similar security value in order to remain competative. Overall this should help lift the image of bitcoin trading.

Well done! (and best of luck)

I wonder how Mt Gox would do.

Hi everyone,
      The results are in!  https://campbx.com/testnet/main.php

We were tested for >1,000 known vulnerabilities specific to our platform and services by McAfee Secure (formerly McAfee Hacker-Safe), who are ranked #1 in security industry for threat detection.  This is the same auditing service used by well-known brands like Costco, Petco, and Roush Racing for their e-commerce websites.


Here is an executive summary of our results:

OWASP top-10 web vulnerabilities:
    A1: Injection - Pass
    A2: Cross-Site Scripting (XSS) - Pass
    A3: Broken Authentication and Session Management - Pass
    A4: Insecure Direct Object References - Pass
    A5: Cross-Site Request Forgery (CSRF) - Pass
    A6: Security Misconfiguration - Pass
    A7: Insecure Cryptographic Storage - Pass
    A8: Failure to Restrict URL Access - Pass
    A9: Insufficient Transport Layer Protection - Pass
    A10: Unvalidated Redirects and Forwards - Pass

Distributed Denial-of-Service attack: Pass with no noticeable slowdown in response time

All vulnerabilities are classified on a scale of 1-to-5, with 5 being Urgent and 1 being informational.  Camp BX final scorecard is:
Sev 5: zero
Sev 4: zero
Sev 3: zero
Sev 2: zero
Sev 1: 29
(Sev 1 includes information like "DNS Server detected", "NTP Server detected", "SSL Certificate mismatch on Testnet.CampBX.com"...)


This makes Camp BX is  the first Bitcoin platform certified for compliance with 7 information and data security standards!  

We have also achieved all requirements for the McAfee Secure Trustmark, and on our livenet launch Camp BX platform will proudly wear this badge.  A HUGE thank you to Alex and Yuriy for burning the midnight oil to fix all issues identified, and ensuring that we are able to achieve this crucial certification prior to our launch.


Going forward Camp BX will be re-tested daily for all known vulnerabilities.  We realize that security is a process, and we have put together alerts and escalation procedures in place to ensure that anything higher than Sev 1 is fixed within 72 hours.


Thank you and good night,
      Keyur