Bank Security Madness

This has probably been said by countless people before, but banking security is just mind bogglingly dumb.

Yesterday I phoned the NAB bank. Along with the usual questions I was asked to name a recent transaction. I couldn't recall one so I asked my wife who was standing next to me. The phone operator proceeded to tell me that I wasn't allowed to ask her because I was the person who needed to know the answer! NAB, if you make me communicate with my wife using a pen and paper instead, then you're not going to gain any security, you're just going to annoy customers.

The next thing that struck me was that the transaction used for authentication could be a debit. Now, generally speaking you don't need to do any authentication to put money into an account. Anyone can deposit into your account as long as they have the account number; thereby rendering this authentication method (as it stands) useless at best.

Today I phoned the ANZ bank. Their system is straight forward enough. I just need to know my Customer Reference Number, my telecode, my security code, and my web password. And I'd better well be able to remember which is which before I run out of attempts.

Authentication is a hard problem to solve, but surely we can do a bit better than this.

Javascript dictionary using objects as keys

One thing that bugs me about Javascript is the inability to have a dictionary with objects as keys. Objects are dictionaries, but essentially toString gets called on anything you use as a key, which isn't always very helpful.

Typical solutions are to call stringify on each object, which is relatively slow and doesn't guarantee reference equality, or to have a custom hashing function, which feels like unnecessary effort. (The jshashtable library generally looks useful, but unless you provide the hashing function the performance drops considerably.

So my requirements are:

• A dictionary that takes objects as keys
• And will only resolve values using the same instance of the object (not just some string match)
• Is fast
• Without any custom hashing functions

It took a little while to realize that since the key is an object, the value can be stored directly on it, so long as we know which property the value got stored in. Job done. But because my poor head wants to deal with something like a traditional dictionary API, it can be achieved something like this:

function Dict() {
    Dict.id = (Dict.id || 0) + 1;
    this._prop = '_dict' + Dict.id;
}
Dict.prototype = {
    add: function(key, value) {
        key[this._prop] = value;
    },
    contains: function(key) {
        return typeof key[this._prop] != 'undefined';
    },
    get: function(key) {
        return key[this._prop];
    },
    remove: function(key) {
        delete key[this._prop];
    }
};

// Sample usage
var a = {};
var b = {};
var c = {};

var dict1 = new Dict();
dict1.add(a, 123);
dict1.add(b, 456);
var dict2 = new Dict();
dict2.add(c, 789);

alert(dict1.get(a));         // 123
alert(dict1.contains(c));    // false
alert(dict2.contains(c));    // true
dict2.remove(c);
alert(dict2.contains(c));    // false

OK, it needs a whole lot more work, but you get the idea. We keep track of a global ID so that a key can be used in more than one dictionary simultaneously. If we want to have some way to enumerate over the values or get a count, then we'd also need to store keys/values in the Dictionary itself. I'd probably go with a doubly-linked-list, otherwise add/removes would get slow.

The main disadvantage is that we are adding an extra property to the key objects, which may be undesirable in some circumstances. But overall it solves the requirements without too much mess.