What if financial systems were hacked
worldif.economist.com
worldif.economist.com
Our systems are as shitty as any other industry, security problems are there, and social engineering is a problem. However, there is one simple rule which allows us to worry less about possible hacks, and when this rule is broken for some reason, shit usually hits the fan (like in the case of Bangladesh heist).
The rule is: it always should be possible to manually reverse the transaction.
Ethereum got it right. Welcome to the real finance.
Well, ethereum classic fork seems to be still alive, and many exchanges are considering adding it. So, it was reversable, but the work and the after-effects were pretty big. The reversability in older systems is pretty much easier.
In a financial transaction there are two parties, and both must agree to a reversal. Especially if you want to reverse thousands of transactions. Unless there are special circumstances. But in no way will it always be possible to manually reverse a transaction.
Ethereum reversed the transaction because of a TBTF situation.
The DAO (a Layer 2 system built on Ethereum) accumulated too much of the entire market cap of the underlying Ethereum network, making it a threat to the underlying network. THEN the DAO failed, threatening the entire underlying Layer 1 network (the blockchain and its ecosystem of miners).
Were it not for the possibility of existential threat (TBTF) then no fork would have been possible, regardless of how much fraud it enabled or how many bugs were found.
The problem is that the crypto community is choosing to not see this for what it is: the inherent systemic vulnerability of a L2 system running on an L1 blockchain. If another DAO - or Lightning Network - or any "L2" system running on top of a crypto garners enough capital from the underlying network, then the L2 system is a weapon that can be used to damage the L1 network.
Crypto enthusiasts should take this as a grim warning: L2 applications can hijack the L1 network and damage it. For this reason, we should be skeptical of any L2 network with excess capitalization.
We should be even more skeptical of any group of devs trying to foist an L2 solution on the community as a one-size-fits-all solution (to distributed apps, to transaction scaling, etc).
Can't tell you how many offices and server closets I walked into and had to ask the question "Hey, what's this machine do?" or "Hey, what's this laptop plugged in for?"
Also lots of "This network is wired in a way that totally doesn't match the spec/use case/documentation."
The construction and cleaning contractors we had had full access to our most secure rooms as well as anyone in the IT department.
The potential for insider and socially-engineered grift is huge.
Regulations will make it progressively harder for newcomers to compete in the marketplace, executive pay will keep rising, corporations will get bigger. Owners of capital won't be able to trust outsiders so they will only recruit their family and close friends into well-paid executive positions. Advertising will completely dominate consumer behaviour; small businesses will disappear; once virtual reality takes over, corporations will make sure that customers forget that these small companies even exist.
Machines will replace people in the workplace. The rich won't care because at that point; because of social tensions and advertising, rich people will have grown to literally hate the poor and want them dead.
Fortunately there are some small wins, like these little fish going to jail: http://www.bbc.com/news/business-36737666 but we need to keep it up and restore accountability.
https://www.bloomberg.com/view/articles/2015-04-01/dutch-ban...
In our semi-globalized world, you can take HUGE risks and make a COMPLETE MESS of your reputation and credit rating in your home country, but then you can move to a different country (and often, you can also bring along your dirty money with you) and start fresh as though nothing ever happened. Unless you're a major public figure; no one will know what a crook you are.
A partially-globalized world is a perfect world for crooks. I think we should either give up on globalization completely or go full steam ahead and merge into a 'world government' under which everyone can be held accountable for their past behaviour without any loopholes.
(spoiler alert: poor rising up, overthrowing, etc.)
Why would you want to enslave much people today, especially when half of them are expected to be of age 40+?
Likely because machines are single function and people are multifunction, you'll also need people to maintain those machines.
Then there is the less savory reasons.
Then the robots will use the bodies of poor people as fertilizer for crops.
The rich won't even know that there was an uprising at all (the robots won't report it) - Because the robots' only duties will be to increase the comfort and happiness of their masters - No need to encumber their masters with 'operational details' related to the 'management' of 'wildlife' and and agriculture.
And how can it be shown that bad actors manipulating the old system haven't somehow seeded the new system for their future advantage (either to sabotage it, or more likely to just disappear with their gains from damaging the old system).
How long would it take to recover from that? Would it even be recoverable?
I don't think any of the big banks employ enough IT people to recover tens of thousands of servers in time to save the world's economies from a major collapse. Recovering from such a situation would take months. Not only that but let's assume they hire temporary contractors to do the work... Can you even vet that many people that quickly? You'll be handing these folks some of the world's most sensitive information.
The Fed needs "IT stress testing" in addition to their balance sheet stress tests. They need to ask these sorts of questions: "If half your servers were deleted how long would it take to recover from backups?" "Demonstrate a backup recovery on the following ten randomly-selected servers right now. You have 8 hours. Good luck!"
2. Pretty much every transaction with the bank has a counterparty that is outside the bank.
It would be recoverable. But very very painful.
There was a talk last year at DefCon that went over mainframe vulnerabilities, and it was like a playground. The biggest barrier to entry is getting a mainframe to experiment with.
Is there a barrier to emulating these systems? It's probably difficult (illegal?) to emulate the various Tandem operating systems on virtual hardware, but I'm sure there's a way.
I'd be shocked if there wasn't a turnkey AS/400 VM available.
Not sure about OS/400 (IBM i) emulation, but you can get accounts to play with it seems -
http://stackoverflow.com/questions/3487895/as400-emulator-or...
It's not clear how good compliance with this actually is.
In other words, the compliance level is actually pretty good, but the solutions themselves are weak and not hardened against intent (just normal operating use).
I believe the technical term for this pattern is Event Sourcing. See also:
http://martinfowler.com/eaaDev/EventSourcing.html
Event Sourcing describes everything of such a system, except for a mechanism to ensure non-tempering. That's where other technologies such as regularily published hash values come into play - which may be printed in newspapers, cryptographically signed by multiple trusted organizations, agreed on through some blockchain technoloy, or a combination of all.
> What we've used for a decade or so.
The linked Fowler article is from 2005, which is also more than a decade old.
> Fowler is [...] unrelated to the basics of this discussion
While Event Sourcing doesn't describe audit logs and storage systems, it does describe how to build a whole working system based solely on that, with real-world experience warnings about pitfalls and so on.
However, recovering internal state is not really a solution to the main problem - you can't reverse any external transactions that were done based on the temporarily wrong state. If ATM or teller handed out cash, you can't simply cancel that. If you (as a bank) sent a payment instruction to another bank or some payment network, you're often not going to get that money back; especially if it was fraud instead of some mistake.
I wonder if it's possible to specifically cancel the serial numbers of the cash that was fraudulently withdrawn. In other words, make it no longer legal tender. Of course, the problem is how the acceptor of the cash knows that it is fraudulent, but perhaps a public list of serial numbers known to be fraudulent would be a start?
But in an automatic way, no, a public list of known fraudulent serial numbers would not be sufficient in the current legal environment; it would be impractical to mandate everyone to check such a list at every transaction for every single banknote.
There's an essential problem: all security systems can be compromised. When a security system seems more safe than the others, more people will use that system, thereby increasing the incentive for adversaries to try to break it (and almost always they will succeed).
You actually decrease it. The payout of tampering is associsted with assets security scheme protects. As for that point, vendors should sell the solutions as reducing but not eliminating risk. Plus encourage monitoring and audits.
The real goal is to make the cost of tampering exceed the payout. The standard mechanisms for increasing the cost are computational power needed (cryptography) and ability to participate in mainstream society (legislation).
Why not? If we restrict ourselves to sovereign, first world central banks (i.e. the Fed, the BoE, the ECB, et cetera), a bank holiday (to reconcile records) followed by a liquidity injection would not only be expected, it would have direct precedent from FDR's bank holiday on 6 March 1933.
There's a popular notion to "not blame the victim" when it comes to many other crimes (e.g. rape). Because long-standing culture traditions or implicit biases can be involved, it's not almost glaringly obvious that somebody is blaming the victim. As such, it's become a kind of litmus test: you look for warning signs that some policy or statement is (even unintentionally) laying the blame on the victim. And that habit is easily transferred to new misconduct, such as hacking.
I think we need to step back and understand why we should not blame the victim for other crimes: I'd argue it is not because they're already suffering, but because the best way to prevent the problem is by focusing on (A) those we can influence and (B) those best placed to prevent the problem. Often that's not the victim - but sometimes it is. In many sex-crimes, the perpetrator is socially well-respected and in a position of power, so that's a (typically) a man that can be influenced (satisfies A), and since he's using his position of power he apparently has it; so he's well placed to prevent the problem (satisfies B).
So for example, we might prosecute people breaking into cars. But most people realize that we're not likely to catch enough thieves to really reduce theftto a minimum, so we also invest in locks, and we teach people not to leave valuables in sight. This is a form of blaming the victim - justifiably so, since I'd argue that if you left your car unlocked and/or leave valuables in sight you're not just hurting yourself, you're hurting others too: you're making theft easy, and by making it worthwhile, you may encourage thieves to try more frequently - also against other targets.
For another example, consider vaccination. Failure to vaccinate make cause the victim to become sick (or their kids to become sick). But here too, it's not just themselves they hurt; they hurt others by propagating dangerous diseases. Beyond a certain level, they'll contribute to epidemics that can hurt even the vaccinated since no vaccine is perfect.
From the perspective of preventing harm, protecting yourself from malicious hacks is more like a cross between theft prevention and vaccines, and not like preventing rape by a powerful individual. Most hacks are trivially easy to prevent (it often takes numerous bugs, mis-designs, and some social engineering to gain access) if there were systematic effort to prevent hacks, so the victim is in a place to prevent the harm from occurring. And since it takes considerable organization to run most vulnerable services in the first place, the victim is also one we can influence.
Focusing on the hackers isn't just futile, it's actively harmful in several ways. Not only is it obvious that many hackers cannot currently be found, many are beyond the reach of law enforcement by virtue of living elsewhere (or at least, acting through not-entirely cooperative countries). So it's immediately apparent that's it's never going to suffice to focus on the perpetrators (they don't satisfy A: we can't influence them). But also, by focusing on the hackers, we help keep vulnerabilities secret. Would you rather be hacked by a script kiddy or by an unscrupulous competitor or hostile country? Hiding vulnerabilities rather than fixing them means that the vast majority of hackers that can never be caught simply have more targets. Additionally, by focusing on hackers, we draw attention away from those that can bear the responsibility to prevent hacks: the victims. And that lets them get off the hook too easily. Most companies suffer rather few consequences for running infrastructure that is, in essence, a public menace. And much like theft and vaccination examples, they hurt others by remaining vulnerable. When an organization is hacked, it affects not just it, but many others. In a data leak, most harm is usually suffered by those who's data is leaked, not by the company holding the data. And when financial infrastructure is hacked then it's not just the organization running it that is harmed, but in particular those that rely on it.
In short: we need a sea-change. To really address the risks posed by hacking, we need to stop focusing on hackers, and instead blame the victim. By failing to defend themselves they are hurting themselves and others, and focusing on hackers is never going to work anyway (and indeed makes it less likely that vulnerabilities are discovered by non-malicious or mildly malicious actors rather than those really motivated and out to get you).
This is dangerous stuff when a small hack can destroy peoples lives.
It's really tiring to see bitcoin promoted as some sort of second-coming-of-Christ when all evidence points to it being nothing more than an interesting experiment.
When it won't be enough, Lightning network will be adapted, as there will be a need for it. Premature scaling is the root of all evil. :)
It's like saying that banks allow you to send money instantly, because you can just give cash to your friend by hand.
Giving cash to a friend still requires me to withdraw the cash from an ATM, pass it to the friend, who then needs to deposit it using a deposit ATM or visit his branch.
One involves a few clicks on your online banking website, the other requires a much longer process. The backend company isn't really relevant, what is relevant is that 'Faster Payments' has been used as a marketing term for 'near instant bank transfers' that transparently use FPSL as a backend.
Not at all equivalent.
Not when it's someone malicious exfiltrating your money.
With the banking system, you generally have some recourse - they're legally responsible for refunding you in some cases, they're able to cancel or claw back transactions in some cases, etc.
TL;DR: It's nice not to be totally fucked for a small mistake.
The problem with Bitcoin is that you are your own bank. Implementing personal bank-level security is hard. There is no tech support to call and no authority except your own.