Bitcoin Forum
December 09, 2016, 07:50:37 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 »  All
  Print  
Author Topic: Bitcoin Stock Exchange Security Standards  (Read 13647 times)
ikonic
Newbie
*
Offline Offline

Activity: 15


View Profile
June 23, 2011, 01:37:27 PM
 #21

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.
1481269837
Hero Member
*
Offline Offline

Posts: 1481269837

View Profile Personal Message (Offline)

Ignore
1481269837
Reply with quote  #2

1481269837
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481269837
Hero Member
*
Offline Offline

Posts: 1481269837

View Profile Personal Message (Offline)

Ignore
1481269837
Reply with quote  #2

1481269837
Report to moderator
1481269837
Hero Member
*
Offline Offline

Posts: 1481269837

View Profile Personal Message (Offline)

Ignore
1481269837
Reply with quote  #2

1481269837
Report to moderator
JohnDoe
Sr. Member
****
Offline Offline

Activity: 392



View Profile
June 23, 2011, 06:22:51 PM
 #22

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
Hero Member
*****
Offline Offline

Activity: 540


So much code.


View Profile WWW
June 23, 2011, 06:34:38 PM
 #23

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?

PGP KEY | 1Bitcoin3Tg2KWyAq3wzivdqwYqGwKYaGd
Nefario
Hero Member
*****
Offline Offline

Activity: 602


GLBSE Support support@glbse.com


View Profile WWW
June 23, 2011, 07:32:18 PM
 #24



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.

PGP key id at pgp.mit.edu 0xA68F4B7C

To get help and support for GLBSE please email support@glbse.com
enmaku
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
June 23, 2011, 07:54:42 PM
 #25

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
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
June 23, 2011, 08:10:41 PM
 #26

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
Jr. Member
*
Offline Offline

Activity: 42


View Profile
June 23, 2011, 08:24:46 PM
 #27

Quote
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

How can you tell when a politician is lying? His lips are moving. A little girl asked her father, 'do all fairy tales begin with "Once upon a time"? The father replied, 'No, some begin with - If I am elected.' How come political leaders don't have all the answers until they write their memoirs?
Findeton
Full Member
***
Offline Offline

Activity: 126


View Profile
June 23, 2011, 08:27:20 PM
 #28

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.

Bitcoin Weekly, bitcoin analysis and commentary

14DD7MhRXuw3KDuyUuXvAsRcK4KXTT36XA
Nefario
Hero Member
*****
Offline Offline

Activity: 602


GLBSE Support support@glbse.com


View Profile WWW
June 23, 2011, 08:46:27 PM
 #29

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

PGP key id at pgp.mit.edu 0xA68F4B7C

To get help and support for GLBSE please email support@glbse.com
enmaku
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
June 23, 2011, 08:54:20 PM
 #30

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

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
Jr. Member
*
Offline Offline

Activity: 56



View Profile
June 23, 2011, 09:32:49 PM
 #31

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
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
June 23, 2011, 11:49:58 PM
 #32

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 Smiley

ikonic
Newbie
*
Offline Offline

Activity: 15


View Profile
June 24, 2011, 02:42:11 AM
 #33

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 Smiley

You could use Rijndael instead
enmaku
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
June 24, 2011, 02:45:11 AM
 #34

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 Smiley

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
Sr. Member
****
Offline Offline

Activity: 454



View Profile
June 24, 2011, 02:48:14 AM
 #35

If funds are needed, send me a PM.

Maria.
ikonic
Newbie
*
Offline Offline

Activity: 15


View Profile
June 24, 2011, 03:05:05 AM
 #36

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 Smiley

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
Member
**
Offline Offline

Activity: 105



View Profile
June 24, 2011, 03:10:54 AM
 #37

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
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
June 24, 2011, 03:28:14 AM
 #38

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 Smiley

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

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
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
June 24, 2011, 02:45:19 PM
 #39

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  Grin

davout
Legendary
*
Offline Offline

Activity: 1358


1davout


View Profile WWW
June 24, 2011, 02:52:31 PM
 #40

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

Pages: « 1 [2] 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!