<p>You should assume your site is going to be hacked, and design with that in mind.</p>

<p>Blaming things on "poor coding" is a get out. There will always be bugs. You must be sure your procedures, your protocols, are faultless despite these bugs.</p>

<p>The majority of bitcoins should be in offline storage, and your hot wallet should be on its own dedicated server, with access through some kind of very limited API that does sanity checks and rate limiting on everything. (Access could be through a custom and very carefully written daemon i.e. not just some Apache HTTP API with associated vulnerabilities!)</p>

<p>Ideally, the user owns an encryption key that is used to somehow client side sign transactions (or any other action they take) which are applied to their account or the hot wallet.</p>

<p>Even then, a hacker could presumably hijack the serving of your pages, modify the crypto etc to steal their key. But at least if the user's key was only generated once and is only used by them occasionally, the chance for massive theft is reduced. Two factor auth may help too.</p>

<p>You could have daemons on other hidden servers that regularly check your site and its resources for tampering, suspending everything if necessary. Perhaps release a browser add-on which verifies your site. Your entire site could be signed, and the add-on could request a new signature to verify any changes. (And you perform this signing offline). As long as the user's browser or the add-on publishing system doesn't get compromised, you'll be alright ;)</p>

<p>To summarise all that:</p>

<ul>
<li>client side encryption/authorisation of any action a user can take</li>
<li>this simply tunnels through the terribly insecure WWW/apache etc layer to a very limited access highly secure "hot wallet" server</li>
<li>some way of verifying that client side encryption is not compromised, e.g. watchdogs running on IPs unknown to attackers</li>
<li>(and lots of other watchdogs all over the place which halt service at the slightest cause for concern)</li>
</ul>

<p>You'll do all this and then your hosting provider will be compromised by social engineering.</p>

<p>At the end of the day, all said and done, your most effective protection will be the offline cold wallet with manual (and slow and annoying) transfers of customer's funds, and regular audits to check all funds are actually there (mtgox lol).</p>

<p>btw, this is written by somebody with no background in security, imagine what somebody who <em>did</em> have such a background might write ;)</p>

<p>Final point: If you are thinking of running a wallet service, don't. Just don't. Give up now. It's going to end in tears, and death threats.</p>

CC BY-SA 3.0
2014-04-04T15:05:14.520Z
2014-04-04T15:05:14.520Z
user18443
<p>When designing a security system first you must decide on the level of security needed. What level of security are you looking for? How many $/coin will this be protecting? What are the attacks you are protecting against?</p>

<p>There are high end devices that self-destruct on detection of tampering or attack used by the banking industry and other places keys need to be secured, if you are creating a large-scale site definitely look into that option. As an example Apple uses HSMs (Hardware Security Modules)) to secure their message service user keys.</p>

<p>If you are concerned about PHP or scripting languages in general use a compiled language for the secure portion of the site. Separate the secure portion from the user facing portion of the site. By segregating the security portion into a self contained section the actual security portion will be smaller and thus easier to vet. Also reduce the interface to the secure portion and validate all inputs. You do not want the secure code intermingled with the entire site.</p>

<p>When I designed mass market security products I paid a top level security expert to vet my design and implementation. His first questions were along the line of what I asked above and more. Cost was about $2,000/day. </p>

<p>Pay attention to the answer by @user18443.</p>

CC BY-SA 3.0
2014-04-04T14:32:35.797Z
2014-04-04T15:16:27.937Z
2014-04-04T15:16:27.937Z
zaph
<p>There are two things a hacker may try to get hold on your coins first is vulnerability in your code and second is to bruteforce your server to get access. In most of the cases PHP vulnerabilities are found when they make an effect on the website because every programmer thinks that his code is secure enough to be hacked. Among both of these PHP is more easy to get compromised(I am not saying that PHP is not secure). I suggest you to ask people(if you may know any security expert or hacker) to penetrate the code and try to find a vulnerability or you may start a bounty for that.</p>

CC BY-SA 3.0
2014-03-05T13:17:44.513Z
Right. I'm pretty good with security, but you're absolutely right. A second and third pair of eyes are great! I'm inviting some local friends who work in security over for a weekend hackathon before the site launches. We'll eat pizza, and run every kind of attack we can think of against the thing. I just don't want to look like an idiot, if there's anything else I can think of ahead of time that I'm not on top of. And I certainly don't want to get goxed after the fact.
Yitzhak
CC BY-SA 3.0
2014-03-06T16:32:17.660Z
I wish you luck with your website and suggest you not to keep all the bitcoins on the server. If you get hacked that means you are growing :P
Khan Shahrukh
CC BY-SA 3.0
2014-03-05T12:51:16.753Z
2014-03-05T12:51:16.753Z
Khan Shahrukh
<p>Nearly every attack I've ever read about has involved bad website coding in one fashion or another. Like that that attack on the Doge wallet site in December, where they allegedly injected the website, and got in through a quirk in Apache to modify the source code, which allowed the alleged crooks to allegedly modify the destination of the transactions by replacing a variable with a hard coded address, that led to their wallet --thereby stealing new transactions and withdrawals. It's been the same or similar with most other attacks on sites that store wallets on the server that I've read about.</p>

<p>So the importance of coding a secure multi-tiered website is very important. I need to watch for injection attacks, apache permissions issues, and open ports, and all the usual stuff I would watch for on a site where money is changing hands. Got it.</p>

<p>But is it always poor website coding that causes site owners to lose money? Is there anything a potential vandal or cracker can do in order to compromise my site in other ways? Also, is there a whitepaper on building bitcoin protocol empowered websites securely, anywhere?</p>

<p>Thanks in advance for your time.</p>

<bitcoind><development><php>
So how would someone steal coins from my site?
Yitzhak
# So how would someone steal coins from my site?

(Asked by: username_0 on 2014-03-05)

Nearly every attack I've ever read about has involved bad website coding in one fashion or another. Like that that attack on the Doge wallet site in December, where they allegedly injected the website, and got in through a quirk in Apache to modify the source code, which allowed the alleged crooks to allegedly modify the destination of the transactions by replacing a variable with a hard coded address, that led to their wallet --thereby stealing new transactions and withdrawals. It's been the same or similar with most other attacks on sites that store wallets on the server that I've read about.

So the importance of coding a secure multi-tiered website is very important. I need to watch for injection attacks, apache permissions issues, and open ports, and all the usual stuff I would watch for on a site where money is changing hands. Got it.

But is it always poor website coding that causes site owners to lose money? Is there anything a potential vandal or cracker can do in order to compromise my site in other ways? Also, is there a whitepaper on building bitcoin protocol empowered websites securely, anywhere?

Thanks in advance for your time.

**Tags:** bitcoind, development, php


---

## 3 answers

### Answer by username_1 on 2014-04-04. Score: 1

You should assume your site is going to be hacked, and design with that in mind.

Blaming things on "poor coding" is a get out. There will always be bugs. You must be sure your procedures, your protocols, are faultless despite these bugs.

The majority of bitcoins should be in offline storage, and your hot wallet should be on its own dedicated server, with access through some kind of very limited API that does sanity checks and rate limiting on everything. (Access could be through a custom and very carefully written daemon i.e. not just some Apache HTTP API with associated vulnerabilities!)

Ideally, the user owns an encryption key that is used to somehow client side sign transactions (or any other action they take) which are applied to their account or the hot wallet.

Even then, a hacker could presumably hijack the serving of your pages, modify the crypto etc to steal their key. But at least if the user's key was only generated once and is only used by them occasionally, the chance for massive theft is reduced. Two factor auth may help too.

You could have daemons on other hidden servers that regularly check your site and its resources for tampering, suspending everything if necessary. Perhaps release a browser add-on which verifies your site. Your entire site could be signed, and the add-on could request a new signature to verify any changes. (And you perform this signing offline). As long as the user's browser or the add-on publishing system doesn't get compromised, you'll be alright ;)

To summarise all that:

* client side encryption/authorisation of any action a user can take
* this simply tunnels through the terribly insecure WWW/apache etc layer to a very limited access highly secure "hot wallet" server
* some way of verifying that client side encryption is not compromised, e.g. watchdogs running on IPs unknown to attackers
* (and lots of other watchdogs all over the place which halt service at the slightest cause for concern)

You'll do all this and then your hosting provider will be compromised by social engineering.

At the end of the day, all said and done, your most effective protection will be the offline cold wallet with manual (and slow and annoying) transfers of customer's funds, and regular audits to check all funds are actually there (mtgox lol).

btw, this is written by somebody with no background in security, imagine what somebody who *did* have such a background might write ;)

Final point: If you are thinking of running a wallet service, don't. Just don't. Give up now. It's going to end in tears, and death threats.


---

### Answer by username_2 on 2014-04-04. Score: 0

When designing a security system first you must decide on the level of security needed. What level of security are you looking for? How many $/coin will this be protecting? What are the attacks you are protecting against?

There are high end devices that self-destruct on detection of tampering or attack used by the banking industry and other places keys need to be secured, if you are creating a large-scale site definitely look into that option. As an example Apple uses HSMs (Hardware Security Modules)) to secure their message service user keys.

If you are concerned about PHP or scripting languages in general use a compiled language for the secure portion of the site. Separate the secure portion from the user facing portion of the site. By segregating the security portion into a self contained section the actual security portion will be smaller and thus easier to vet. Also reduce the interface to the secure portion and validate all inputs. You do not want the secure code intermingled with the entire site.

When I designed mass market security products I paid a top level security expert to vet my design and implementation. His first questions were along the line of what I asked above and more. Cost was about $2,000/day.

Pay attention to the answer by @username_1.


---

### Answer by username_3 on 2014-03-05. Score: 0

There are two things a hacker may try to get hold on your coins first is vulnerability in your code and second is to bruteforce your server to get access. In most of the cases PHP vulnerabilities are found when they make an effect on the website because every programmer thinks that his code is secure enough to be hacked. Among both of these PHP is more easy to get compromised(I am not saying that PHP is not secure). I suggest you to ask people(if you may know any security expert or hacker) to penetrate the code and try to find a vulnerability or you may start a bounty for that.

> **Comments:**
> **username_0**: Right. I'm pretty good with security, but you're absolutely right. A second and third pair of eyes are great! I'm inviting some local friends who work in security over for a weekend hackathon before the site launches. We'll eat pizza, and run every kind of attack we can think of against the thing. I just don't want to look like an idiot, if there's anything else I can think of ahead of time that I'm not on top of. And I certainly don't want to get goxed after the fact.  
> **username_3**: I wish you luck with your website and suggest you not to keep all the bitcoins on the server. If you get hacked that means you are growing :P  

---

