[E-Lang] MintMaker with ACLs

Tyler Close tclose@oilspace.com
Tue, 30 Jan 2001 11:01:28 -0000

Hal Finney wrote:
> My Mint has a number of customers, each identified by a
> public account
> number and a secret password.  Each customer has a balance, which is
> the amount of money they have.  The Mint will receive a message from
> a customer, giving his account number and authenticating
> himself with
> his password.  The only message I'll show is one which
> transfers money
> to another account, identified by account number:
>     // account balances, indexed by account number
>     int balance[];
>     // passwords, indexed by account number
>     String storedPassword[];
>     // Message requesting transfer
>     int transfer (int sourceAccount, String password, int
> destAccount, int amount)
>     {
>         if( password != storedPassword[sourceAccount )
>             return ERROR_BADPASSWORD;
>         if( balance[sourceAccount] < amount )
>             return ERROR_INSUFFICIENTFUNDS;
>         // Proceed with transfer
>         balance[sourceAccount] -= amount;
>         balance[destAccount]   += amount;
>         return NOERROR;
>     }

The password is a coarse grained authority over each customer's entire
account. This makes for a very inflexible interface. For example, say
there was an account history feature:

	 int[] getHistory(int account, String password)

To get your accountant to prepare your income tax return for you, you
would end up also handing over the ability to make new payments. Your
response will probably be that there would be a second password for
this history access; however, it should be clear that this approach to
the problem will lead to a multitude of passwords as more roles are

More sinister, is the reality that a payment clearinghouse is a large
piece of software. It will not be written by a single individual. All
parts of the software (GUI, etc) will need the account password in
order to perform their function. If any one of these parts is
malicious, or just buggy, the entire account can be compromised. The
opportunity to introduce such a security flaw is widespread.
Localizing the error is difficult.

The way you are using the password isn't exactly like an ACL system.
In an ACL system, the password is intrinsic to the invoker. The
invokee is able to magically determine the invoker and check the
authority. In your design, you are explicitly passing the password on
each invocation. This makes it more like a capability. If you combined
the srcAccount and password parameters into a single parameter, it
would be a capability.

Still, there is the separation of designation and authority and so the
possibility of a confused deputy attack. Say you were offering a
publicly viewable balance. The software (deputy) offering this service
would have to have your account password (authority). Clients of this
software can easily obtain the designation for your account (the
account number). Both the designation and the authority for a
transfer() are present. There exists the possibility that the deputy
could be confused into making a withdrawal. I am having trouble coming
up with a plausible scenario of this exploit, but you can see that the
roots of one are present.

This is only a simple example. It should be clear that the same design
techniques applied to a larger project would surely lead to a
multiplicity of exploits.