Topic: Bitcoin Stock Exchange Security Standards (Read 14685 times)

If you can make this happen, I'll be flipping BitCoins daily.

Very nice thread, which I'd like to throw in my 5 BTC cents to

First of all I'm also amazed by simplicity of implementation of existing exchanges (GLBSE seems like a more decent implementation). However, I don't think any kind of this "standard" is needed, because all those lame exchanges will just die out because they will never gain popularity. Especially using such methods as referral codes makes it like some pyramid scheme instead of a real exchange.

So, even though I was developing a futures exchange at first, I decided to apply all my experience, team up with a skilled PHP web dev to create a decent and serious "stock exchange" (codename ICBIT) whose primary goal would be to support currency exchange. Later, the universal trading engine would allow to introduce futures trading too.

Some of the features, which I already defined before this thread appeared, so it may be interesting to discuss:

• Security is our nr. 1 priority: The exchange is based on industry proven software solutions, developed with security in mind from day 0.
• Fees: There would be no fee for any additional security measures we take (2 factor authentication, yubikey support, etc).
• Speed: ICBIT is developed with intraday trading in mind, so executing thousands of traders per hour is not a problem
• Compatibility: Besides web-based trading, ICBIT also aims to support an industry standard FIX gateway for secure and fast trading terminals, and FAST for realtime data streaming
• Data export: Ability to use technical analysis software of your choice (Metastock-compatible or custom export will be possible)
• For futures trading we plan to provide market making so that your contracts are always liquid, no need to wait hours for a buy/sell offer

One of the most important decisions is to base as much as possible on existing software for registration, authentication, etc which is proven to have good security measures and is not hackable.

This turned out to be almost the project announcement, but really I would be interested in your comments, because I don't want ICBIT to be a project popped out of nowhere. It should be a community project, an exchange which I and you (as a community member) would trust and use. Not some totally closed and unknown project.

I will be glad to provide more comments about the proposed systems architecture, also there are more unsolved questions like how it is better to organize money deposit and withdrawal to prevent using the exchange as a place to convert e.g. LR USD into some other payment system USD without any fees.

At some point in the chain someone must be trusted. Either you trust a single party(the exchange) and they centrally handle the bitcoin, allowing the market to function

or

You trust that each member of the market will honour their side of the agreement and send the bitcoin/money.

In the end someone must be trusted, you either find one trustworthy person and operate an exchange or you have many with less required trust but a higher chance of them running away.

The bigger question is what do you do when a trusted exchange suddenly decides to take all your bitcoins and disappear? Which leads to another question: how do you know an exchange can be trusted?

Until you involve a few lawyers from a few countries that could answer those questions, you can't really consider any exchanges to be trustworthy no matter how secure they claim to be.

Great ideas. Keep them coming!

Are we doing this my friend? I am waiting for you.

Maria.

Side-Note: MT Gox is Awesome! We have serious competition.

I guess the focus is toward fine graining access controls so if you can do this on the DB you are using then either way is fine.

Its another layer in the toolbox and if you are running a decent firewall that has packet inspection you can kill most stuff before it gets to the server

Agreed, but most development and QA environments are never matched to production.

Agreed

Nope, apart from Oracle Java we are all open source. Linux/Eclipse/gcc/PostgreSQL/Apache/Tomcat etc...

English is not my native language, though.   

You sound like a .Net developer, you probably are one

Yea better store the passwords in plaintext, that'll be a nice performance optimization.

When the web server is handling the password hashing via BCrypt... Yes. 

BCrypt is just a bit resource intensive...

Sounds to me like you have split the business logic between the DB and the web server? I guess you could call that increased security, but I see it mostly as a complication.

An ecommerce project I've been working on for the past couple of years has 3 layers. The DB is separate from the business logic which is separate from the web app... The BLL isn't internet accessible, and the DB isn't accessible even from the web server at all. The BLL and the web app talk to one another via an XML API.


The DB is probably doing most of the work anyway, so are you sure it's improving performance?

In addition to the salt data stored with the hashed password and the validation fields I'm keeping on each row, there's also an additional application-specific salt that exists only in the stored procedures which, of course, have the "WITH ENCRYPTION" flag set. This adds an extra layer of difficulty to password cracking attempts since not all of the salt data will be known to an attacker without first going through SQL's built-in encryption.

I also have validation fields on each row of every table such that inserts or updates made without going through the stored procs will be considered invalid. Every stored proc re-validates every record it touches and locks the account if invalid records are found. There is no way to buy, sell, deposit or withdraw bitcoins without a correct validation field and the validation fields are SHA512 with both stored salt data and additional salt in the encrypted stored procedures.

Stored procs which update this validation number require their own validation in the form of a session key which is a hashed amalgam of both a large random number and browser fingerprint data, such that if the cookie were stolen (a la firesheep) it would still be useless without also faking HTTP headers, IP address etc. These session keys are stored in a manner similar to password hashes and are invalidated at the database level after ten minutes of inactivity. This is also my method for enforcing a ten minute auto-logout on idle: if your session key in the database is null, every page redirects to login.

So never say never... Anything can be used as a tool to increase security, it all depends on how you use it. I chose to enforce a lot of my security and data integrity rules at the database level rather than at the web server or application level. Since SQL resides on a separate server which is not internet accessible, it places much of my infrastructure behind at least one more layer of security.

P.S.: As an added benefit, the offloading of many transaction processing and security tasks to stored procedures also allows me to split the load more evenly between the CPUs of my web server and my SQL server, thus increasing the transaction rate that I can handle with the same hardware.

-- NO passwords stored on server or client side.

-- ALL transaction requests must be client-signed. (Any password is entered on the client side, and is not stored anywhere. Server verifies signature before processing transaction.) This prevents hackers from accessing your account funds unless they have a copy of your private key AND your passphrase.

-- All transaction receipts must be server-signed (and must contain a copy of the original client-signed request.) This prevents the server from forging any of your transactions.

-- Receipt should prove current balance, with the newest receipt is always the winner in any dispute. (Meaning the receipt IS the account.) This prevents the server from changing your balance without permission.

-- Receipt should also prove which instruments are valid and which transactions have cleared. (Meaning the receipt IS the transaction history.)

-- All recurring transactions (such as trades processing over time from a specific market offer) should result in a receipt in the user's inbox.

-- All market trades should contain a copy of the user's original signed offer, as well as details on how many trades have processed from the offer.

-- Users should have to sign a new receipt every time they clear their inbox. (The server can never change your balance without your sign-off.)

-- All server requests must contain a request number that increments with each message. This prevents attackers from intercepting messages and sending them again.

-- All server requests must contain the server ID that the message is intended for. This prevents attackers from intercepting messages and sending them to other servers.

-- All transactions must contain a transaction number that was previously issued (and signed for). These numbers must be listed on every receipt until signed as closed. (Server can prove entire transaction history without having to store it.)

-- All transactions must contain a signed balance agreement. All receipts must be verifiable against the current inbox and the last signed balance agreement.

-- All Bitcoins must be bailed into a system such that individual servers cannot steal bitcoins from their own users. (Or be hacked and have hackers steal bitcoins from their users.)

-- All currencies issued on the server, including Bitcoins, must have reserves that are publicly auditable.

-- Users should sign all transactions on a crypto-card.

-- An additional layer should be provided via crypto-tokens with passwords that change every 90 seconds.

-- Accounts and transactions should be possible that require multiple signers.


OT already does nearly all of these.  The last 5 are "coming soon".

https://github.com/FellowTraveler/Open-Transactions/wiki

Prepared statements, yes, stored procs, NO.

SPs never really increase security (unless you are talking about the DA's job security), but they do complicate the design. Therefore, you shouldn't use them "just because". Most apps these days use some form of ORM and a minimal set of sprocs, if any.


Security though obscurity isn't real security. The hacker isn't going to look at your headers and then run a specific exploit script; they'll just run them all and then some. My Apache logs are full of attempts to exploit IIS vulnerabilities, every day.

Also you can't really expect the client to honor any particular headers, either. (You should still use the security attributes, ofc, just don't count on them working).


- Don't invent your own cryptography.
- Use the Unix crypt scheme with a NIST approved algorithm for password hashing.
- Require strong passwords.
- Introduce some sort of one-time password scheme in addition to the static one.
- Don't do wish-it-was-two-factor. It's just unnecessary if not embarrasing.


There is no need to purge anything if you follow a proper release managment process.

You should have at least three different environments: development, QA and production. Dev never sees the production data, and it's where you do all your development and most of your analysis. QA is a replica of the production, used for testing the releases before moving them into production. QA can also serve as a backup when production goes down.

You can have different kinds of access schemes, but basically only a select few should have any type of access to production (or QA) DB or OS (or even apps).


You could use a 48+ hour average or something.

There could be rules to detect suspicious activity (sudden spikes in volume etc) which could trigger safety measures, such as seizing trade and withdrawals completely until the activity has been audited.

Oh, I wasn't really mentioning you
I meant that if there are authentication frameworks available for your language you should use them. For example if you do rails, then use the devise gem.

The reason we're doing it different is because the status quo is very vulnerable.

Also we're the only ones doing this, so it's going to be others using our code.

Protip : don't write/rewrite a login system, use someone else's

Bah, never mind, it'd probably be enough work to implement the n-round SHA that I might as well just rewrite the login system from scratch... Which I think is what I'll do.

I started off thinking I could reuse some code but I'd rather do it right - and at this point there's no question of whether or not it's too much work for me to follow through. It's WAY too much work but I'm STILL following through.

It should be a badge of honor for this community that you've got me interested enough in a project to actually do something more than throw ideas around 

That's what I'm using. Their library doesn't implement the HashAlgorithm class and I can't for the life of me create a usable wrapper for it. I could just be having a massive brainfart though, if you happen to find a way to wrap the thing please please please let me know, I'd love to use it - otherwise I'm pretty much spent with the whole BCrypt thing.

Also, I've now played with Rijndael enough to slap myself in the forehead and remember that it's a symmetric encryption algo, not a hashing algo - the last thing I want to do is store passwords in any kind of reversible manner... GetHashCode() was entirely the wrong method to reference but hey, I've been going at this for almost 12 hours today and my brain is pretty much fried from dealing with crypto. Maybe it'll all make sense again in the morning after some nice refreshing sleep and a hot cup of coffee? 

Hey, thought... What if I did occasional benchmarks automatically to see how many rounds of SHA1/SHA512/whatever it takes to eat up N milliseconds? It might not be as advanced or future-proof as BCrypt, but it would be dead simple and if I specified long enough (200+ ms perhaps) it'd probably amount to thousands of rounds. THAT would be easy enough to override in a usable way and I could just store the ever-shifting number of rounds alongside the hash. If I forced password resets at a reasonable interval, it would also ensure that the only way the # of iterations ever got low enough to become insecure is if an account was simply abandoned for a very long time.

Let's not forget to put the site on a secure server in a secure data center.  Here is an example: http://www.gsihosting.com/services/infrastructure/datacenters/

GSI hosting packages start at $700/month.

I am looking for partners to go in on a hosting plan of this caliber.  I'm not committed to using GSI.

Please PM me if you're interested in getting involved.