Topic: Bitcoin Stock Exchange Security Standards - page 2. (Read 14706 times)

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

If funds are needed, send me a PM.

Maria.

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?

You could use Rijndael instead

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

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.

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?

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.

Don't use SHA512.

Use bcrypt.

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

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?

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)

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.

Shall we build an open-source platform for this?

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?

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.

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.

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.

Just use KeepassX, so you are also safe from simple keyloggers.

Agreed, Bitmarket.eu has this extremely simple function, whereby any changes (to your email address, BTC withdrawal address, etc) has to be confirmed through a two step process. Simple and effective.