MPex has never been hacked.
check out what they do
Topic: Lessons we've learned from all the thefts? (Read 719 times)
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
I'm starting this thread to ask about the lessons we've learned from Bitcoin thefts regarding security. We've seen exchanges, pools, online wallets get hacked despite the fact that they were maintained by people who knew what they were doing and despite every theft/hack we still end up with security holes.
If I wanted to start a Bitcoin service, how would I proceed to design my service as to avoid the attacks used on other websites and exchanges?
So far I've made a list of things that can go wrong:
CSRF Attacks and XSS. CSRF can, at least on paper, be mitigated by having some unique identifier every time you reload a page and every time a form is submitted, it's compared to the one in the database and later re-generated. In case AJAX-like features are implemented, a different approach is required. XSS is a matter of escaping html, but I believe straight out disallowing '<' and '>' from being entered in a field is also possible as well as avoiding printing dynamic data from a GET request.
SQL Injection. This is possibly the most common vector of attack. From all I've read about it, using prepared statements where it's claimed that data is escaped for you should be more than sufficient. And avoiding concatenation of parameters when doing it. Avoiding any use of addslashes is encouraged as it has a quirk that allows it to mutate a byte to a different one thereby allowing you to bypass it.
Plaintext password. This is probably the first thing that one should fix, by hashing the password a few times with salt. Personally I would use double SHA-512 with salt OR even scrypt if need be. I would store the password as a BLOB conserving space as a 512 bit hash is 128 bytes in ASCII Hex, so you conserve 64 bytes per password by storing it in binary. I was also thinking of the use of reversible scrambling algorithm on the data in the database in case the attacker obtained a SQL dump. This way an attacker would need access to the actual source code of your service to see the algorithm.
You are free to fill in the blanks. I am by no means a security expert, this is just what I think should solve a few of the problems.
If I wanted to start a Bitcoin service, how would I proceed to design my service as to avoid the attacks used on other websites and exchanges?
So far I've made a list of things that can go wrong:
CSRF Attacks and XSS. CSRF can, at least on paper, be mitigated by having some unique identifier every time you reload a page and every time a form is submitted, it's compared to the one in the database and later re-generated. In case AJAX-like features are implemented, a different approach is required. XSS is a matter of escaping html, but I believe straight out disallowing '<' and '>' from being entered in a field is also possible as well as avoiding printing dynamic data from a GET request.
SQL Injection. This is possibly the most common vector of attack. From all I've read about it, using prepared statements where it's claimed that data is escaped for you should be more than sufficient. And avoiding concatenation of parameters when doing it. Avoiding any use of addslashes is encouraged as it has a quirk that allows it to mutate a byte to a different one thereby allowing you to bypass it.
Plaintext password. This is probably the first thing that one should fix, by hashing the password a few times with salt. Personally I would use double SHA-512 with salt OR even scrypt if need be. I would store the password as a BLOB conserving space as a 512 bit hash is 128 bytes in ASCII Hex, so you conserve 64 bytes per password by storing it in binary. I was also thinking of the use of reversible scrambling algorithm on the data in the database in case the attacker obtained a SQL dump. This way an attacker would need access to the actual source code of your service to see the algorithm.
You are free to fill in the blanks. I am by no means a security expert, this is just what I think should solve a few of the problems.
Jump to: