Bitcoin Stock Exchange Security Standards

[ikonic]

Are we talking about stock exchange,like glbse, or currency exchange, like mt gox and tradehill?

The more I think about it, it should really be an across the board for standard for any site that deals with bitcoins.

The finance industry is going to be bound by PCI one day and something similar should happen for bit coin sites.

A simple e-mail notification when BTC withdrawal address is changed, and lock on withdrawing funds for at least 24 hours after address change, would be nice too (BTCGuild's method)

I'd like to have to have an option of having a code sent to my mobile with a code in it to activate the withdraw. Make the mobile number unchangeable after registration. Only way to change it is when the account has zero balances. Even if the account is hacked, good luck withdrawing.

Mobile TANS are probably the most secure (barring MITM attacks) but this is something that should come into play. You could also consider the VIP solution from Verisign but that would have a significant cost.

[1713936473]

1713936473

[1713936473]

1713936473

[JohnDoe]

I'm not sure that maximum transfer requirements should be part of the standard as it may hurt users who legitimately need to withdraw a lot of money quickly. Maybe just leave it as a recommendation?

[Clark]

The more I think about it, it should really be an across the board for standard for any site that deals with bitcoins.

Shall we build an open-source platform for this?

[Nefario]

Seems like someones having a party and forgot to invite me.

First a suggestion on the name. Bitcoin Exchange Standards(BES), that way it covers stock, asset and currency exchanges.

Now let me tell you kiddies how we do things down at GLBSE.com(GLobal Bitcoin Stock Exchange).

We have no identifying information for account holders. When you create an account a RSA keypair is created.

We keep the public key, and a hash of the public key is your user id(we keep no emails no nothing).

You keep the private key.

We have 2 clients, command line and web based.

And they both pretty much work the same.

They use a protocol called
VOP, Verified Order Protocol.

A json encode hash with the users id, a nonce, and request specific fields is base64 encoded.

The private key is used to sign this b64json, the signature is also base64 encoded.

Both are sent to the server in a single http post request.

The nonce is extracted, and checked against a nonce record. Having a nonce for each request prevents the same request being sent twice (say, at a later time by an attacker).

The signature and user id is extracted from the request.

The public key for that id is used to verify the requests signature.

If it's ok, then it's OK and all goes ahead.

If it's not (say changed by a some attacker) then the server returns an error and nothing more is processed.

Client
The web client is a single html page in which everything is done in Javascript (including the RSA signing), we're currently making changes to make it easier to store the private keys in the clients browser securely.

If you're more security concerned (worried about some rogue website script stealing your keys) then the command line client is for you. Written in python, with the private key stored locally and encrypted with a password.

Server
We don't use sessions, or anything to track between requests, don't need to, and it opens up holes.
By cutting down on what the server is trying to do (only verify if a request is legit, and then processing it, no gui stuff) we cut down on the scope of where vulnerabilities can fit in.

The server is meant to act as a finite state machine.
All input is checked, and returns errors if not correct.

We will be opensourcing the GLBSE platform in about 4 months.

Next

Our next step is going to be to allow people to build currency exchage front ends, that don't hold any bitcoin, the front ends sole role is to handle interfacing with the bank account and manage customers deposits and withdrawls to the currency exchange.

The bitcoin itself is kept safe and sound on glbse.com, and GLBSE becomes the unified market that all the currency is traded on.

Lets assume mtgox and britcoin started having front ends to GLBSE, then when users deposited money to mtgox or britcoin bank accounts they automatically get issued mtgox.USD or brit.GBP assets on GLBSE which they can then trade, safely and securely.

So in short kiddies, keep it simple, keep it safe.

Questions, suggestions and any security holes(real and theoretical) please post below, happy to hear about them.

Nefario.

[enmaku]

The more I think about it, it should really be an across the board for standard for any site that deals with bitcoins.

The finance industry is going to be bound by PCI one day and something similar should happen for bit coin sites.

PCI is actually a really terrible standard - little more than the lowest possible baseline they could've set. Also, while it might apply to the finance industry some day, it currently is meaningless to anyone but merchants and those who supply hardware / software to said merchants. BTC actually takes a lot of the load off of merchants since the whole thing is built secure from the ground up instead of relying on nonsense like sending credit card numbers in plaintext, which then requires merchants deal with HTTPS unnecessarily.

For the record, I do support (almost) everything that's been said so far about security for exchanges I just wanted to clarify that despite vague-sounding comments, they don't necessarily apply to merchants.

I'm actually working on some ASP.NET / C# code for another project right now that already meets many of these requirements... Now that I realize how close I already am to the mark I might just spend the time to make an exchange that implements (most of) these suggestions.

I don't have iterative hashing just yet, but SHA512 with a nice long salt seems fairly strong to me. If I do modify for iterative hashing I'd also throw an extra application-specific salt into the (encrypted) stored procedure just so we're not storing ALL the data right there in the table(s). I do use cookies (session variables SUCK without them) but all cookies are encrypted with very short timeouts. I also use rotating session keys to validate everything users do. Every row of every table has a "validation" field which contains an SHA1 hash of all data in that row plus an application-specific salt and the stored procs that contain that salt are all encrypted of course. The "validation" field prevents attackers from simply updating a row - all changes must go through stored procedures which of course all require some form of re-authentication.

So if (and that's a big IF) I were to modify my already-existing code, what non-obvious measures should I throw in the mix? (and seriously, non-obvious measures... I know to parameterize my fscking inputs)

[enmaku]

Oh and one more thing I've picked up whilst working in the casino management software industry... Our security is usually just as crappy as banks but our accounting and transparency is bar none. I'm hoping the above will make it significantly harder for anyone to pull something like the Mt. Gox incident, but even if they do it's just as important to have regular audits. Imagine if the Mt. Gox hack weren't a big obvious 500,000 BTC move but a large number of tiny transactions over a long period of time. How long would it have been before MT noticed the transactions adding up to meaningful numbers?

[dennis_sweden]

The BCSE is a great tool, but can get you into some serious trouble with the SEC if you do any sort of public offering through it.  I've spoken with a lawyer who specializes in this area (securities law) about it, and we came to the conclusion that it would be legitimate ONLY for non-public offerings -- for example, where you approached each person individually and got them to invest...  You could also put the offering/alert on a password-protected page, and be safe.  But if the offering is on an open page, viewable by the public, then you are making a public offering, and must register it with the SEC.

And those people who invest privately CANNOT SELL THOSE STOCKS publicly either.  

In other words, if I privately approached Jack, John, and Jeff for investments, and they agreed, then their stocks can only legally be traded among each other, or bought back by the company itself.

Epinnoia

What is the BCSE? I have tried to google it but do not find any relevant information. This topic really interests me, so could you please say what the acronym stands for.

EDITED MYSELF, SOMETIMES MY BRAIN WORKS SLOWER THAN A CRETIN

[Findeton]

I don't have iterative hashing just yet, but SHA512 with a nice long salt seems fairly strong to me. If I do modify for iterative hashing I'd also throw an extra application-specific salt into the (encrypted) stored procedure just so we're not storing ALL the data right there in the table(s). I do use cookies (session variables SUCK without them) but all cookies are encrypted with very short timeouts. I also use rotating session keys to validate everything users do. Every row of every table has a "validation" field which contains an SHA1 hash of all data in that row plus an application-specific salt and the stored procs that contain that salt are all encrypted of course. The "validation" field prevents attackers from simply updating a row - all changes must go through stored procedures which of course all require some form of re-authentication.

So if (and that's a big IF) I were to modify my already-existing code, what non-obvious measures should I throw in the mix? (and seriously, non-obvious measures... I know to parameterize my fscking inputs)

Don't use SHA512.

Use bcrypt.

[Nefario]

................
I don't have iterative hashing just yet, but SHA512 with a nice long salt seems fairly strong to me. If I do modify for iterative hashing I'd also throw an extra application-specific salt into the (encrypted) stored procedure just so we're not storing ALL the data right there in the table(s)............

Nooooooooooooooooooo

SHA-ANYTHING is not to be used to hash passwords, it doesn't anymore tha md5. The time it takes to hash something with SHA* is meant to be low, it's meant to be a fast hash.

Use BCrypt and set the interative value very high, so it takes like 1 second to do the hash, there are plenty of libraries out there.

Fast hashes are the reason that hackers are able to break scores of passwords when DB's are compromised, it doesn't take long to hash a single password, so they can go through millions of combinations in seconds.

If it takes 1 second just to run the hash once then they're not going to crack any passwords.

Of course the best option is not to have passwords at all.

dennis_sweden , it's GLBSE, the GLobal Bitcoin Stock Exchange (glbse.com)

Nefario.

[enmaku]

OK, found a BCrypt library for C#, now I just have to tweak everything else to actually implement it 

I haven't read the documenI'm assuming this is the "difficulty" value:

    // Blowfish parameters.
    private const int BLOWFISH_NUM_ROUNDS = 16;

I don't have a server available to test on at this exact moment, anyone know if the 16 round default is enough or have a suggestion on where I should set it?

[joan]

I like the idea of security guidelines for Bitcoin sites.
We do have technical information on how to create Bitcoin based web services on the wiki, it would be nice to consolidate a set of security best practices as well.

It should be of interest to anyone holding bitcoins on behalf of others, not only exchanges. (Online wallets, Escrows, Lotteries, etc. Basically anything outside of simple merchants)

Some ideas:
- A test period of at least several weeks running on testnet or with very limited volume per user.
- During this period, bounties for finding and reporting vulnerabilities.

[enmaku]

Except that the only BCrypt library I can find doesn't implement the HashAlgorithm class so I can't use it with my existing solution. I'd have to rewrite the entire login system... Which I might still do... We'll see

[ikonic]

Except that the only BCrypt library I can find doesn't implement the HashAlgorithm class so I can't use it with my existing solution. I'd have to rewrite the entire login system... Which I might still do... We'll see

You could use Rijndael instead

[enmaku]

Except that the only BCrypt library I can find doesn't implement the HashAlgorithm class so I can't use it with my existing solution. I'd have to rewrite the entire login system... Which I might still do... We'll see

You could use Rijndael instead

Well, hey, if it's got a GetHashCode() method (which it appears to) I can use it with the code I've got, the only question is how does it compare to BCrypt? I'm obviously not a crypto expert considering I was going to use an SHA variant so what does the crowd think?

[Maria]

If funds are needed, send me a PM.

Maria.

[ikonic]

Except that the only BCrypt library I can find doesn't implement the HashAlgorithm class so I can't use it with my existing solution. I'd have to rewrite the entire login system... Which I might still do... We'll see

You could use Rijndael instead

Well, hey, if it's got a GetHashCode() method (which it appears to) I can use it with the code I've got, the only question is how does it compare to BCrypt? I'm obviously not a crypto expert considering I was going to use an SHA variant so what does the crowd think?

have seen http://bcrypt.codeplex.com/

[matt.collier]

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.

[enmaku]

Except that the only BCrypt library I can find doesn't implement the HashAlgorithm class so I can't use it with my existing solution. I'd have to rewrite the entire login system... Which I might still do... We'll see

You could use Rijndael instead

Well, hey, if it's got a GetHashCode() method (which it appears to) I can use it with the code I've got, the only question is how does it compare to BCrypt? I'm obviously not a crypto expert considering I was going to use an SHA variant so what does the crowd think?

have seen http://bcrypt.codeplex.com/

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.

[enmaku]

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 

[davout]

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