Bitcoin Forum
April 23, 2014, 02:24:51 PM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
   Home   Help Search Donate Login Register  
Pages: 1 2 3 [All]
  Print  
Author Topic: Bitcoin Stock Exchange Security Standards  (Read 5669 times)
ikonic
Newbie
*
Offline Offline

Activity: 15


View Profile

Ignore
June 21, 2011, 02:50:41 AM
 #1

Given that BitCoin is still in its infancy, many of the stock exchanges are being run by inexperienced coders or business types with no real online financial experience... and as such, putting the entire community at risk.

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.

As an example of Web Standards, the basics would be

Web Application Requirements
  • Website to be tested to ensure SQL injections (including truncation attacks) do not exist
  • Website to be tested to ensure XSS injections do not exist
  • Website to be tested to ensure XPATH injections do not exist
  • Website to be tested to ensure CSRF vulnerabilities do not exist
  • All transactional functionality should be undertaken with http post using CSRF nuonces
  • Any and all interaction with the database should done using either Stored or Prepared Procedures

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

Data Storage and Analysis Requirements
  • All passwords should be stored using one way encryption with a unique salt per user (salt to be a minimum 128bits)
  • Where the need for database analysis is required the data should be purged of all PII prior to be delivered to the auditor
  • Users with permissions to the database should be limited to the web application only

Finally, this list isn't extensive but only a start so it would be good to get others feedback.

btw: Sorry about being stuck in the newb section but alas such is life.

Note: Not here for the MT Gox bashing, it will achieve nothing. Lets talk about the future instead.

Edit:
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?

BitCoin Transfer Requirements
  • Maximum Daily Transfer Limit - Currency $1000
  • Maximum Daily Transfer Limit - BitCoins 1000


Unbeatable Service & Product Support
Grab Your Miners at GAWMiners.com
Order Before April 25th to receive
Double your Hashing Power for 1 week!

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

Posts: 1398263091

View Profile Personal Message (Offline)

Ignore
1398263091
Reply with quote  #2

1398263091
Report to moderator
muad_dib
Member
**
Offline Offline

Activity: 84


View Profile

Ignore
June 21, 2011, 09:13:34 AM
 #2

well 1000 bitcoins are a lot of money.

Moreover we need 2 levels of password:

1) An account password, sent via password-authenticated key agreement and not https

2) A Time-synchronized one-time passwords or a 2d key, to authorize movements, so that even if the password is stolen, it is impossible to authorize another transaction.


Users should not be allowed to choose passwords. A 25 characters long, strongly randomized password should be generated for the user, so he's forced to use something like keepassx.




I think we need an independent security committee to write a security standard and certify exchanges.
piuk
Hero Member
*****
Offline Offline

Activity: 910



View Profile WWW

Ignore
June 21, 2011, 09:20:53 AM
 #3

Exchange code should be open source like britcoin.

hamdi
Hero Member
*****
Offline Offline

Activity: 504



View Profile

Ignore
June 21, 2011, 09:23:12 AM
 #4

no use of cookies at all.

Superform
Jr. Member
*
Offline Offline

Activity: 56


View Profile

Ignore
June 21, 2011, 09:26:56 AM
 #5

if anyone wants to colaborate on a proper exchange I can help with supplying a domain bitcoin-market.com

I also have over 10 years of share trading experience

another suggestion is the exchange should issue a username which is a random string of numbers/letters instead of using your email name etc


1P4pSRP6mZTt17TkEEA7aPMzKqUYGbYytn
like my post? send me some btc Smiley
Epinnoia
Full Member
***
Offline Offline

Activity: 187


View Profile

Ignore
June 21, 2011, 11:35:54 AM
 #6

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.



My first miner -> ATI 4550 (7.2 Mh/sec): 
https://www.facebook.com/groups/cryptospeculators/
Findeton
Full Member
***
Offline Offline

Activity: 126


View Profile

Ignore
June 21, 2011, 11:44:12 AM
 #7

Yes, we do need regulation. This kind of regulation.

Bitcoin Weekly, bitcoin analysis and commentary

14DD7MhRXuw3KDuyUuXvAsRcK4KXTT36XA
davout
Staff
Hero Member
*****
Offline Offline

Activity: 1148


1davout


View Profile WWW

Ignore
June 21, 2011, 11:47:41 AM
 #8

All passwords should be stored using one way encryption with a unique salt per user (salt to be a minimum 128bits) iterative hashing
Fixed that for you.

ikonic
Newbie
*
Offline Offline

Activity: 15


View Profile

Ignore
June 21, 2011, 11:47:08 PM
 #9

well 1000 bitcoins are a lot of money.
Perhaps accounts should have daily transaction limits where the user can reduce online at any time but it requires admin intervention to raise.

Moreover we need 2 levels of password:
1) An account password, sent via password-authenticated key agreement and not https

2) A Time-synchronized one-time passwords or a 2d key, to authorize movements, so that even if the password is stolen, it is impossible to authorize another transaction.
I assume you're talking about a TAN? This is a good idea.

no use of cookies at all.
Not really a big fan of this, It means the URL requires a session identifier to be included or then entire site runs through POSTS?

All passwords should be stored using one way encryption with a unique salt per user (salt to be a minimum 128bits) iterative hashing
Fixed that for you.
thx
DonnyCMU
Full Member
***
Offline Offline

Activity: 142



View Profile

Ignore
June 22, 2011, 12:46:20 AM
 #10

Users should not be allowed to choose passwords. A 25 characters long, strongly randomized password should be generated for the user, so he's forced to use something like keepassx.

Ridiculous. If I have 5 bitcoins in my account and want to use 'boobies' as my password, it should be my own rights, my own problem, at my own risk!

Most security-minded people never bother to see how usable these measures are.

Don't you hate it when you always use a simple password for non-important login, and then there's this silly site that demand the password for you to log-in and play flash games must contain 2 numbers, 3 signs, and 1 egyptian hieroglyph???
Anonymous
Guest

June 22, 2011, 12:49:16 AM
 #11

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.


These pedantic laws have nothing on people who trade anonymously under the veil of the sovereign web. The SEC is irrelevant. Any regulation they try to throw at Bitcoin exchanges is irrelevant.
Chick
Member
**
Offline Offline

Activity: 70


View Profile

Ignore
June 22, 2011, 12:51:06 AM
 #12

Given that BitCoin is still in its infancy, many of the stock exchanges are being run by inexperienced coders or business types with no real online financial experience... and as such, putting the entire community at risk.

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.

As an example of Web Standards, the basics would be


Web Application Requirements
  • Website to be tested to ensure SQL injections (including truncation attacks) do not exist
  • Website to be tested to ensure XSS injections do not exist
  • Website to be tested to ensure XPATH injections do not exist
  • Website to be tested to ensure CSRF vulnerabilities do not exist
  • All transactional functionality should be undertaken with http post using CSRF nuonces
  • Any and all interaction with the database should done using either Stored or Prepared Procedures

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

Data Storage and Analysis Requirements
  • All passwords should be stored using one way encryption with a unique salt per user (salt to be a minimum 128bits)
  • Where the need for database analysis is required the data should be purged of all PII prior to be delivered to the auditor
  • Users with permissions to the database should be limited to the web application only

Finally, this list isn't extensive but only a start so it would be good to get others feedback.

btw: Sorry about being stuck in the newb section but alas such is life.

Note: Not here for the MT Gox bashing, it will achieve nothing. Lets talk about the future instead.

Edit:
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?

BitCoin Transfer Requirements
  • Maximum Daily Transfer Limit - Currency $1000
  • Maximum Daily Transfer Limit - BitCoins 1000


To sum it all up, BANK LEVEL SECURITY. No bullshit "25 letter passwords".

Take my money and STFU.

ikonic
Newbie
*
Offline Offline

Activity: 15


View Profile

Ignore
June 22, 2011, 01:06:09 AM
 #13

To sum it all up, BANK LEVEL SECURITY. No bullshit "25 letter passwords".
Take my money and STFU.
I am actually the senior developer/team leader for the online banking team which provide online services (mobile and internet banking/lending) to around 30 financial instituions. I also run a security forum and am familar with the nuoance of online transactions.

In saying that, I am not going to drop every single piece of information straight up unless others are interested in participating.

And BANK LEVEL SECURITY is shit. Just ask the CitiBank customers who card details have been nabbed...

What I am proposing is something far more secure and workable.
Findeton
Full Member
***
Offline Offline

Activity: 126


View Profile

Ignore
June 22, 2011, 02:37:00 PM
 #14

To sum it all up, BANK LEVEL SECURITY. No bullshit "25 letter passwords".
Take my money and STFU.
I am actually the senior developer/team leader for the online banking team which provide online services (mobile and internet banking/lending) to around 30 financial instituions. I also run a security forum and am familar with the nuoance of online transactions.

In saying that, I am not going to drop every single piece of information straight up unless others are interested in participating.

And BANK LEVEL SECURITY is shit. Just ask the CitiBank customers who card details have been nabbed...

What I am proposing is something far more secure and workable.

What about using bcrypt?

Bitcoin Weekly, bitcoin analysis and commentary

14DD7MhRXuw3KDuyUuXvAsRcK4KXTT36XA
davout
Staff
Hero Member
*****
Offline Offline

Activity: 1148


1davout


View Profile WWW

Ignore
June 22, 2011, 02:59:57 PM
 #15

Any regulation they try to throw at Bitcoin exchanges is irrelevant.
Frozen bank accounts are relevant.

Rassah
Hero Member
*****
Offline Offline

Activity: 1064


Director of Bitcoin100


View Profile

Ignore
June 22, 2011, 03:41:49 PM
 #16

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)

Piper67
Hero Member
*****
Offline Offline

Activity: 868


View Profile

Ignore
June 22, 2011, 03:50:12 PM
 #17

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)

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

Activity: 84


View Profile

Ignore
June 23, 2011, 10:46:16 AM
 #18



Ridiculous. If I have 5 bitcoins in my account and want to use 'boobies' as my password, it should be my own rights, my own problem, at my own risk!

Most security-minded people never bother to see how usable these measures are.

Don't you hate it when you always use a simple password for non-important login, and then there's this silly site that demand the password for you to log-in and play flash games must contain 2 numbers, 3 signs, and 1 egyptian hieroglyph???

Just use KeepassX, so you are also safe from simple keyloggers.
killer2021
SCAMMER
Member
*****
Offline Offline

Activity: 84


View Profile

Ignore
June 23, 2011, 12:51:33 PM
 #19

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.

Anonymous Cash-By-Mail Exchange: https://www.bitcoin2cash.com
1H6mqgB6UcqKt2SrCmhjxUp9np1Xrbkdj7
benjamindees
Hero Member
*****
Offline Offline

Activity: 938


View Profile

Ignore
June 23, 2011, 01:02:41 PM
 #20

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

Civil Liberty Through Complex Mathematics
ikonic
Newbie
*
Offline Offline

Activity: 15


View Profile

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

Activity: 392



View Profile

Ignore
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


Lead Developer - ZeroBlock


View Profile WWW

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

ZeroBlock: The Bitcoin Trading Platform.
PGP KEY | 1Bitcoin3Tg2KWyAq3wzivdqwYqGwKYaGd
Nefario
SCAMMER
Hero Member
*****
Offline Offline

Activity: 602


GLBSE Support support@glbse.com


View Profile WWW

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

Assets, Bitcoin Bonds.

GLBSE.com

Get bitcoin capital for your project or organisation


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



View Profile WWW

Ignore
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: 728



View Profile WWW

Ignore
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

Ignore
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

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

Activity: 602


GLBSE Support support@glbse.com


View Profile WWW

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

Assets, Bitcoin Bonds.

GLBSE.com

Get bitcoin capital for your project or organisation


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



View Profile WWW

Ignore
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

Ignore
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: 728



View Profile WWW

Ignore
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

Ignore
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: 728



View Profile WWW

Ignore
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: 441



View Profile

Ignore
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

Ignore
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

Ignore
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: 728



View Profile WWW

Ignore
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: 728



View Profile WWW

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

Activity: 1148


1davout


View Profile WWW

Ignore
June 24, 2011, 02:52:31 PM
 #40

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

Nefario
SCAMMER
Hero Member
*****
Offline Offline

Activity: 602


GLBSE Support support@glbse.com


View Profile WWW

Ignore
June 24, 2011, 03:51:29 PM
 #41

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.

Assets, Bitcoin Bonds.

GLBSE.com

Get bitcoin capital for your project or organisation


PGP key id at pgp.mit.edu 0xA68F4B7C

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

Activity: 1148


1davout


View Profile WWW

Ignore
June 24, 2011, 04:21:04 PM
 #42

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

Activity: 70



View Profile

Ignore
June 24, 2011, 05:29:38 PM
 #43

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

Please send your extra Bitcoins to 17miTorGDBUh3yNTYJtodJPw9wzrcNcf6y. Thank you!

Sign up on TradeHill Instant Bitcoin Exchange using this link to get a lifetime 10 % discount on trades!
fellowtraveler
Sr. Member
****
Offline Offline

Activity: 430


View Profile

Ignore
June 25, 2011, 12:14:53 AM
 #44

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


co-founder and CTO, Monetas
creator and lead developer, Open-Transactions
enmaku
Hero Member
*****
Offline Offline

Activity: 728



View Profile WWW

Ignore
June 27, 2011, 04:54:32 PM
 #45

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

Activity: 70



View Profile

Ignore
June 27, 2011, 05:28:51 PM
 #46

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?

Please send your extra Bitcoins to 17miTorGDBUh3yNTYJtodJPw9wzrcNcf6y. Thank you!

Sign up on TradeHill Instant Bitcoin Exchange using this link to get a lifetime 10 % discount on trades!
enmaku
Hero Member
*****
Offline Offline

Activity: 728



View Profile WWW

Ignore
June 27, 2011, 06:21:09 PM
 #47

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

BCrypt is just a bit resource intensive...

davout
Staff
Hero Member
*****
Offline Offline

Activity: 1148


1davout


View Profile WWW

Ignore
June 27, 2011, 07:45:36 PM
 #48

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 Cheesy

BCrypt is just a bit resource intensive...
Yea better store the passwords in plaintext, that'll be a nice performance optimization.

MikesMechanix
Member
**
Offline Offline

Activity: 70



View Profile

Ignore
June 28, 2011, 07:07:57 AM
 #49

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

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

English is not my native language, though.   Cheesy

Please send your extra Bitcoins to 17miTorGDBUh3yNTYJtodJPw9wzrcNcf6y. Thank you!

Sign up on TradeHill Instant Bitcoin Exchange using this link to get a lifetime 10 % discount on trades!
ikonic
Newbie
*
Offline Offline

Activity: 15


View Profile

Ignore
June 28, 2011, 11:51:54 AM
 #50

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

Activity: 441



View Profile

Ignore
June 28, 2011, 12:30:59 PM
 #51

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

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

Activity: 280


View Profile

Ignore
July 03, 2011, 09:49:37 AM
 #52

Great ideas. Keep them coming!
eugene2k
Jr. Member
*
Offline Offline

Activity: 37


View Profile

Ignore
July 03, 2011, 03:12:08 PM
 #53

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

Activity: 602


GLBSE Support support@glbse.com


View Profile WWW

Ignore
July 03, 2011, 03:44:43 PM
 #54

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.

Assets, Bitcoin Bonds.

GLBSE.com

Get bitcoin capital for your project or organisation


PGP key id at pgp.mit.edu 0xA68F4B7C

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

Activity: 630


View Profile WWW

Ignore
July 03, 2011, 04:33:49 PM
 #55

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

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.

Margin trading platform ICBIT: https://icbit.se
Follow us in Twitter: https://twitter.com/icbit_se
MtRev
Full Member
***
Offline Offline

Activity: 168



View Profile

Ignore
July 03, 2011, 07:29:48 PM
 #56

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

You need a web designer? I'm offering big agency quality, without the big agency invoices!
Drop me a message; will work for BTC, LTC & PPC =]
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!