
Bitstamp problem and warm wallets - homakov
http://homakov.blogspot.com/2015/01/bitstamp-problem-and-warm-wallets.html
======
eterm
The problem with a "warm wallet" is that the hot wallet of 100Btc might need
refilling every hour and so if the attacker just sits draining the hot wallet,
the admins might keep authorising refills letting the attackers take large
amounts before the hole is discovered. If it must be done that frequently then
admins won't bother to audit the hot wallet every time they refill it from the
warm wallet, which makes the warm wallet a hot wallet.

If hot wallet refills are rare, the hot wallet must be sizable, but then the
refills will be sizable too, so an attacker could steal hot wallet (sizable)
and a refill (sizable) at least before discovery.

Each step adds an effective rate limiting step and a chance to catch the hole,
but requiring manual intervention too often and the required auditing and
manual checking will not be done. But any automation just pushes something
from warm to hot.

~~~
ObviousScience
Even with automatic transfers, I think there's a difference between wallets
that are queued up and actively sending money out of the system, and wallets
that are queued up to do so (or to refill that wallet). The difference lies in
the fact that they do serve as an automated rate limiting point, and have
different methods for the hackers to extract out funds from them.

An example: if you have one hot wallet with the keys loaded in to the system,
and a secondary warm wallet (basically, a wallet that will be swapped in as
the hot wallet when the other runs out), you can secure the details of the
warm wallet better, meaning that certain read access vulnerabilities will only
be able to target the hot wallet. Of course, an attacker can empty the hot
wallet, and then the details of the warm wallet will be exposed when it is
loaded because of the same vulnerability, but this forces the system to have a
chance to validate the current state of the world before the second wallet
becomes vulnerable, which is not the case if both were being used as loaded
hot wallets.

There are meaningful automated sanity checks and rate limiting tactics that
can be used with automated warm/hot wallets.

Of course, if you have a $5mil hot wallet, you should probably hire a "bitcoin
banker" or "bitcoin teller" to sit at a workstation and manually deal with
some of these kinds of swaps and oversee the audits. Even if you don't
immediately patch all security holes, you'll have a much better idea of where
you're leaking.

------
Animats
The "manually adds funds" flowchart block looks, to a banker, like a risk
item. How does that work? Every hour or so, some clerk opens a safe full of
USB sticks and takes one out? Now you have an insider theft risk. Did they
copy one? Who has physical access? If you're operating 24/7, more than one
person will need access.

A secure off-line "cold wallet" system is hard. Physically, it looks like a
collection of storage media. Those devices need to be backed up. But backing
them up means making a copy of the private keys, which means the backup medium
and the backup machine have a path into the funds. How do you audit a cold-
wallet device, short of sending the funds in it back to yourself? Looking at
it visually is useless, and reading it out exposes the keys to risk.

Some of these problems have known solutions from bank currency management
operations. But some don't. In currency management, you can count and recount
bills. You don't have to worry whether some of them have been used and
invalidated. Bitcoins in some stored form are not like that. Just because you
have a sealed plastic bag with a USB stick and a label that says "1000 BTC,
validated on 2013-04-21" doesn't mean it's still good. If there was a copy
made at some point, someone else may have the keys to those BTC. Even if they
haven't transferred them yet.

So manual handling isn't a magic bullet. Off-line vault operations for a
sizable Bitcoin operation are going to be complicated and expensive to do
securely, more complicated than bank cash vault operations. We've already seen
what happens when they're not done securely.

~~~
wmf
There's also M-of-N multisignature and HSMs to prevent private keys from being
copied.

~~~
Animats
Unfortunately, there's no vendor in that space with a track record in
security. A major provider of hardware security modules ("hardware wallets")
for Bitcoins was Butterfly Labs. Their Bitcoin mining hardware business did
not work out well for their customers. (As in, forced by the FTC to shut down
and refund customers who paid for hardware and didn't get it.)

There are some little startups selling hardware wallets, or trying to get
funding for doing so, but nobody with a solid track record of protecting large
sums of money has a product. SafeNet and Thales are absent from the Bitcoin
field.

~~~
wmf
Existing HSMs claim to support ECC so I'd hope they can support Bitcoin. I
wonder which HSM CoinKite uses.

------
steakejjs
The API with a single call "createWithdrawl" is very good.

Having code like this to begin with changes how all your future code works. It
also is easier to debug, simpler to explain, etc. You think twice about adding
new API calls, which makes you think twice before you add new bugs. Having the
ability to muck around with API calls you shouldn't be making will catch you
eventually.

I've posted this before, but web-app security in most startups I look at is so
bad. If it's written in PHP, I can normally find every bug in the book in
under 5 minutes. What is worse on top of that is many companies don't respond
(and don't fix) when you report bugs. I'm talking well known startups too.

I really think the OWASP Top 10 needs to be required reading for startup
founders (or technical leads).

------
jpmattia
Essentially, start making exchangers look more like banks, with manual
interventions to evaluate whether transactions are valid.

The bank system (and transaction clearance delays) evolved for good reason. I
suspect that bitcoin will not achieve the validity of fiat until a similar set
of checks and balances are put in place (at least for sizable transactions.)

~~~
sp332
Bank transactions are mostly reversible if someone screws up or commits fraud.
(Edited for clarity)

~~~
homakov
Isn't there protocol to call to another bank and ask them to send it back? Or
at least get info about the account?

------
dthakur
Relevant and possibly more in-depth: "Multi Tiered Cold Storage Scheme"
[https://bitcoinsecurityproject.org/SecureStorage/MultiTiered...](https://bitcoinsecurityproject.org/SecureStorage/MultiTieredColdStorageScheme/)

// plug: check out Celery [https://www.gocelery.com](https://www.gocelery.com)

------
deweller
I take issue with equating web developers and amateurs.

I understand his point. And I conceed that there is a lower barrier to entry
for writing a PHP signup form than a Go systems-level program.

But please don't assume that all web apps are written by 2nd-year junior
programmers. Some of us web developers have the experience required to write
secure web apps.

~~~
ObviousScience
I think the point is that most web developers (even very good, experienced
ones) are amateurs at topics like server security or financial
accounting/controls because those topics are outside of their domain
knowledge.

It takes more than not being a "2nd-year junior programmer" to write secure,
reliable code; it takes specialist knowledge to make a solidly audit-able
financial control system.

~~~
mst
Right, I've been programming for a living somewhere over a decade and while I
certainly consider myself a professional, that's "enough of a professional to
know I don't know nearly enough to write such a thing without expert help".

------
jaekwon
Proof of assets.

Proof of liabilities.

Leaks be instadetected.

