Bitcoin Stock Exchange Security Standards

[Nefario]

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

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.

[1714078710]

1714078710

[1714078710]

1714078710

[davout]

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

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.

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.

[MikesMechanix]

• Any and all interaction with the database should done using either Stored or Prepared Procedures

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.

HTTP Response Header Requirements

• All cookies to have the "HttpOnly" and "Secure" attributes
• HTTP Headers should not include Server OS version
• HTTP Headers should not include Web Server version
• HTTP Headers must include an X-Frame-Options directive

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).

All passwords should be stored using one way encryption with a unique salt per user (salt to be a minimum 128bits)

- 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.

• Where the need for database analysis is required the data should be purged of all PII prior to be delivered to the auditor

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.

• Users with permissions to the database should be limited to the web application only

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).

Another good idea to discuss it the limit that can be transfered daily/hourly.
For instance, setting a maximum dollar amount to transfer out is pointless as you can simply crash the price and pull out. Perhaps a better idea would be to set volume limits instead?

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.

[fellowtraveler]

-- 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

[enmaku]

• Any and all interaction with the database should done using either Stored or Prepared Procedures

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.

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.

[MikesMechanix]

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.

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.

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.

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

[enmaku]

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

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

BCrypt is just a bit resource intensive...

[davout]

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.

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

BCrypt is just a bit resource intensive...

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

[MikesMechanix]

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

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

English is not my native language, though.   

[ikonic]

• Any and all interaction with the database should done using either Stored or Prepared Procedures

Prepared statements, yes, stored procs, NO.

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.

HTTP Response Header Requirements

• All cookies to have the "HttpOnly" and "Secure" attributes
• HTTP Headers should not include Server OS version
• HTTP Headers should not include Web Server version
• HTTP Headers must include an X-Frame-Options directive

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).

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

• Where the need for database analysis is required the data should be purged of all PII prior to be delivered to the auditor

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.

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

Another good idea to discuss it the limit that can be transfered daily/hourly.
For instance, setting a maximum dollar amount to transfer out is pointless as you can simply crash the price and pull out. Perhaps a better idea would be to set volume limits instead?

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.

Agreed

[Maria]

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

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

BCrypt is just a bit resource intensive...

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

Maria.

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

[gigabytecoin]

Great ideas. Keep them coming!

[eugene2k]

Therefore, what I am proposing is that the BitCoin community draft together a set of agreed security standards and best practices that all trusted exchanges should adhere to.

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.

[Nefario]

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.

[Fireball]

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.

[MtRev]

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