Oh, I wasn't really mentioning you
I meant that if there are authentication frameworks available for your language you should use them. For example if you do rails, then use the devise gem.

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

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.


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

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

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

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.

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

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

Agreed

Great ideas. Keep them coming!

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.

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