Open Financial eXchange (OFX) is Broken (Online Banking Security is a Joke)

Hacker Rene

Am I the only person in the world who thinks that it’s utterly ludicrous that we have to give our passwords to sites like so they can help us keep track of our spending habits? Surely I can’t be the only one. It’s like giving away the keys to the kingdom.

It kind of irks me a little that if I want to use a site like to track my spending habits and help me keep my budget in line, I have to give my username and password over to them.

In fact, the way the underlying technology works, must keep our passwords stored in their system. Not just a hash, but the passwords themselves, since that’s what they have to use in order to access our bank account info. They are stored encrypted, no doubt, but the have to be decrypted in order to be used (see below). has worker programs, “robots”, if you will, which log in to our bank accounts the same way we do (well, not really, but I’m simplifying for the general public), so they have to be able to authenticate as ‘us’. But the problem is, those username/password combos aren’t read-only. may tell you that they have read-only access, but that’s just not true. Anybody who hacks’s database, and is able to decrypt those passwords, has full access to the corresponding bank accounts.

The technology which enables this log-in that and other financial websites use, is called OFX, which is short for Open Financial Exchange.

The part that requires the username and password for every transaction is described in the OFX ‘security’ page (emphasis mine, and BTW, what a fucking joke):

Authentication enables the recipient of a message to verify the identity of the sender. For example, a financial institution or third party processor authenticates a customer by requiring the use of a password and user ID with each transaction. A customer’s application authenticates a financial institution or third party processor by verifying the institution’s digital certificate.

That technology was developed about 10 years ago. (The website looks about 10 years old too — just take a look.) We’ve evolved since then. Technology has evolved. Why the hell has the banking system not caught up yet? (Hint: it’s not in their best interests to improve the security of your bank account. They would have to pay the cost of securing your account, while not seeing any reward for it.)

This should immediately set off red flags for any information security professional. An obvious way to mitigate this risk is to simply enable customers to generate a read-only API key on the bank end, then give out that read-only API key to any party that they wanted to share their info with, on a read-only basis. This would be true read-only access. But that is something that banks themselves would have to implement, and they’re too busy raping the general public with ridiculous fees for things like debit cards, and simply having a deposit account in the first place.

The Solution

The solution? A successor protocol to OFX which requires banks to implement read-only API key access, and which can be controlled by customers, e.g. by allowing depositors to generate their own unlimited number of API keys, read-only or not (depositor’s choice).

A standard has to first be put in place. It would specify that usernames/passwords are no longer allowed, period. All account access would be via API keys, which would be generated on the bank end, controlled by the clients (depositors), and either read-only, read-write, or other combinations. They could be extensible so as to plan for the future.

Then, make all the banks follow the standard. Fines of $XX,XXX,XXX per day after a X-year grace period which allows all banks ample time to convert from OFX to the new standard, NOFX (New OFX).

Hell, I don’t know. Just something. But please, do something to protect the people, instead of just considering the up-front cost of implementation. (There are hidden costs of not implementing something like what I’ve suggested, but most individuals and businesses won’t see them until it’s too late).

Note: This solution isn’t going to happen. This is just an ideal scenario. The banking system is going to be transformed, but not from the inside, not by anyone who had anything to do with this. Technologies like Bitcoin and other cryptocurrencies and trustless systems are going to render insecure protocols like OFX useless. The funny thing is, it’s because the current system will never change which is the reason why it’s going to be pre-empted and destroyed. The market will find a solution.

Bitcoin eliminates PCI compliance

I was just reading up on wrapping APIs and just came to another realization regarding Bitcoin. In a payment system using only Bitcoin, there is absolutely no need for PCI compliance. Zero. That’s right:

Bitcoin eliminates PCI compliance.

There’s no private data to store. No customer data exists that a criminal can then steal and rack up charges. Since Bitcoin payments are a push from the customer, instead of a pull from the merchant, there’s no need for any PCI compliance. Customer security is simply “baked in” to the protocol.

Think of how many millions (probably billions) of dollars are spent by large corporations every year, just to be PCI compliant. I know first-hand that the largest company in the world spends (at least) millions on PCI. There are yearly audits, infrastructure costs galore. All CC data must be encrypted. It’s a huge freaking hassle.

And forget about the small guys. There’s no way small businesses could ever hope to store CC data themselves (and be in compliance with PCI standards) — which is why they have to rely on companies like Stripe and Braintree to accept credit card payments.

I like Stripe and Braintree, but I like even more the fact that millions of dollars can be saved simply by using Bitcoin.

Things like this are what makes Bitcoin so amazing. This is just one example. Bitcoin takes everything we think we “know” about electronic payments and flips it on its head.

Password Policy

Hackers/crackers use modern GPUs (and possibly ASICs) to brute-force passwords. The old-school password policies from the early 2000’s really shouldn’t apply now, because to a computer, it’s irrelevant which characters are which. Computers can run through the entire UTF-8 charset in fractions of a second, and they’ll eventually guess a short password whether or not it contains a mix of character types (upper, lower, numbers, special, etc).

I’m tired of seeing password policies like this (I saw this when trying to change one of my passwords today):

We require that your new password contain the following:

2 upper case letters
2 lower case letter
2 numbers
2 special characters (examples: !@#$%^&*)

This leads to a false sense of security on both the part of users and the site operators.

Anyone still using/enforcing/advocating this kind of password policy needs to read this (I promise it’s very short).

It doesn’t have to be that complicated. I’ve boiled it down to a 2-step process:

  1. enforce a minimum password (or passphrase) length, such as 25+ characters
  2. hash the password using bcrypt or scrypt and store only the hash

Obviously basic steps should be taken, such as preventing passwords from being transmitted in plaintext, but the 2 measures above will prevent 99% of passwords from being cracked.

Analysis of a Chinese Phishing Scam – Global Payments, Inc.

This post will be of particular interest to customers of Global Payments, Inc. I received an email which seemingly came from them, asking for account login details. Since I don’t have an account with them (and before this morning didn’t know who they were), I did some detective work. It turns out to be a phishing scam.

The fraudulent practice of sending e-mails purporting to be from legitimate companies in order to induce individuals to reveal personal or confidential information, such as such as credit card numbers or passwords by directing a user to a fake email message or website.

Do not trust any emails coming from the domain “”, e.g. “”. This is not the company “Global Payments, Inc.” (which itself is a valid company), but a phishing scam intended to get you to enter your real payment processor login data, which the scammers will then use to access your real account and take all your real monies.

A Google search did not turn anything up, so I did a little investigating myself. The HTML form in the email accepts your login info and sends it to a script at the domain. A “whois” search reveals that this is a Chinese domain:

Domain Name..........
  Creation Date........ 2007-04-08 11:12:47
  Registration Date.... 2007-04-08 11:12:47
  Expiry Date.......... 2016-04-08 11:12:47
  Organisation Name.... fu jianshida ruanjian
  Organisation Address. fujianshifandaxue ruanjianrencaipeiyangjidi
  Organisation Address.
  Organisation Address. fuzhou
  Organisation Address. 350000
  Organisation Address. FJ
  Organisation Address. CN

Admin Name........... lu qixue
  Admin Address........ fujianshifandaxue ruanjianrencaipeiyangjidi
  Admin Address........
  Admin Address........ fuzhou
  Admin Address........ 350000
  Admin Address........ FJ
  Admin Address........ CN
  Admin Email..........
  Admin Phone.......... +86.59187248372
  Admin Fax............ +86.59183560708

Tech Name............ jinfeng wang
  Tech Address......... BeiGuo East Residential District 26-102
  Tech Address.........
  Tech Address......... Nantong
  Tech Address......... 226001
  Tech Address......... JS
  Tech Address......... CN
  Tech Email...........
  Tech Phone........... +86.51385292710
  Tech Fax............. +86.51385292710

Bill Name............ jinfeng wang
  Bill Address......... BeiGuo East Residential District 26-102
  Bill Address.........
  Bill Address......... Nantong
  Bill Address......... 226001
  Bill Address......... JS
  Bill Address......... CN
  Bill Email...........
  Bill Phone........... +86.51385292710
  Bill Fax............. +86.51385292710
  Name Server..........
  Name Server..........

Below is the email I received. Note that I use mutt, a text-based email reader. If you are reading your email on a web browser and are hit with this scam email, the text of the message will be the same as below but you will probably see the HTML form and some image(s).

From: "GlobalPayments, Inc" 
Subject: Account Update

[-- Attachment #1 --]
[-- Type: text/plain, Encoding: 7bit, Size: 0.2K --]

Dear GlobalPayments Customer,

Because we registrated to many frauds we decided to lock your Virtual Terminal account.
To unlock it please download the file attached to this e-mail and update your login info.

2012 Copyright Global Payments ,Inc.

[-- Attachment #2: Login_myvirtualmerchant.html --]
[-- Type: application/html, Encoding: 7bit, Size: 2.2K --]

[-- application/html is unsupported (use 'v' to view this part) --]

[-- Attachment #3 --]
[-- Type: text/plain, Encoding: 7bit, Size: 0K --]

update: Apparently the company Global Payments, Inc. are aware of this scam, as they have an alert on their homepage and a link to a more detailed alert/disclaimer here: