Quote from: ikonic on June 23, 2011, 01:37:27 PM

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)