• Home  
• Sponsors  
• Artists  
• Fundraising, Anti-Spam, More  
• Internals  
• Money Ideas, Links, Search  
• News, Comments  
• About

Secret Accounts Names: Default Is No Password

In the traditional Swiss numbered bank accounts, the depositor gets a random code number to identify the account. Anyone who brings that number in can take the money out, or otherwise manage the account. In these accounts, a secret account name (the number) also serves as a password. (Last we heard, these accounts still exist but are no longer anonymous.)

For RepliCounts, we decided to use something similar, instead of the usual account-name/password for online accounts. The main reason is that the owner of a RepliCount will be able to create many new, independent RepliCounts very easily; managing new, separate passwords for all of them would be a hassle. Also, passwords are not very good security, especially when they travel over the same communication channel as the account name. RepliCounts can let owners add better additional authentication, in the few cases where it's necessary. For example, the owner could set the RepliCount to call the owner's mobile phone to request a PIN to approve transactions that exceed any owner-chosen limit on the amount spent per day, week, or month. And the PIN could be different every time.

Public Accounts

The big disadvantage of a passwordless account is that you can only use it to do business with the bank or other institution where you have the account, not with third parties, since there is no way for them to reference the account without having full owner's access. But RepliCounts solves this problem in a new way, using account replication. The owner can have the secret account reproduce one or more "children" accounts, specially created so that their names can be given out.

These public accounts are "born" with an irrevocable restriction: they can never hold any money, or give any money out. They can take money in, however, and it immediately shows up in the secret parent account. (The public account can give out valuable access or information, such as a copy of a song or other digital content.) Only the owner of the secret parent account will be able to use that money, or even know where it went.

Incidentally, not even the server will store the secret account name, only a hashed version of it -- this is standard in credit-card processing. If the RepliCount's name is truly random and is long enough, then the account owner will almost certainly have the only copy of that name anywhere on Earth -- or anywhere in the entire universe, all of the billions of galaxies and whatever creatures and civilizations they might have contained through billions of years. Probably 200 decimal digits would be more than enough for the latter (a few decades ago someone estimated that 70 digits would be enough to count all the atoms in the then-known universe).

But most account owners, 12 random digits will be enough for most purposes; that would allow up to a million accounts to be issued, with the chance of a random guess hitting any one of them being no more than a million to one. Computers could not break this system by millions of trial-and-error tests, since only the server that manages the accounts can say if a guess is right, and it would recognize the attack long before millions of attempts.

Account Name Formats

In theory, RepliCount names can be any string of symbols that all parties (including computers) involved with the account can handle. In practice, we see three major naming conventions:

1. Decimal numbers have big advantages for international use, and for entry into a traditional telephone or other numeric keypad. New RepliCounts are always created as offspring of existing ones (except for the first RepliCount on a server, of course), and the server might suggest a 12-digit random number and let the owner accept that account name or change it. For security, these secret account names can only be used for secure communication between the owner and the server; the owner can manage the account (including creating offspring) through the owner's dashboard, described below.
2. The public accounts noted above exist to be shared, so usually their names should be easy to remember, not hard to guess. These will likely be alphanumeric, and usually suggested by the account owner; of course the system will require a name not already in use. (We recommend that capitalization should not matter in RepliCount names, due to how the human mind works. Recent password systems often get this wrong, and require both lower and upper case in a password. That's a dumb way to improve security.) Also, the RepliCounts design requires public-account names to be suitable for use in a URL, in the form www.automatic-accounts.org/the-public-account-name. Therefore, spaces and most special characters are not allowed.
3. Owners might want to use a few non-public accounts with easily remembered names for convenient everyday use -- while the RepliCounts with significant money in them sit in an office safe, or hidden at home. These throwaway, convenience RepliCounts may have only a small amount of money in them -- or better, be hardwired to never pay anyone except a single, secret payee, or a secret short list of possible payees. If a criminal makes a lucky guess or otherwise steals an account worth $2, say -- or finds the account unusable, since there is no way to launder money through the trusted payee(s) or even find out who they are, then who cares? Of course the owner will not leave private information in such throwaway accounts, or any information that could help identity theft. The RepliCounts system software will help owners remember that (although they could evade this safety feature if they want to).

The Accounts Database

You can visualize the main database of a RepliCounts system as a huge spreadsheet (Excel or whatever). The rows are the different accounts; there can be millions of them. The columns are the various different values or settings that an account can have; for example, one column will be the amount of money each account currently contains, another column will be the account name. There can be thousands of columns, holding codes or data to control many different account capabilities (including software applications that work within the account itself, for easy integration with money).

This rest of this page assumes more computer background. Skip it if you want.

Our professional computer-programming experience ended more than 20 years ago, when object-oriented programming and relational databases were just coming into general use. So here we designed RepliCounts using more classical methods -- for example, hashed file access for the main database of accounts. Developers can use whatever software tools and methods they want, but for RepliCounts the hashed file access to fixed-length records will be very efficient and reliable. Classical programming methods had to be efficient, because computers were slower then, and had far less internal memory or disk space. In contrast, the relational databases used today have so much overhead that they are often problematic even on today's much faster computers.

Hashed file access is very efficient if you give it plenty of disk space. If that case, the great majority of reads or writes to the file consist of a single physical read or write; there is no other overhead (it's even possible to bypass the operating system, though not recommended). The account name (actually a stand-in for the name, already hashed in a different way, for encryption) will be hashed again with a different algorithm, into a number spread across the disk addresses available for the file. More than one account might point to the same disk address; in these cases, the hashed file access procedure sees that the space is already in use by something else, and tries the next sequential space, and if it is also in use, keeps going until a free one is found. Modern disks have plenty of space; if you can allocate about 10 times more disk memory than will be used, then when the disk is "full" (actually only 10% used) then about 90% of the time only one physical disk read or write will be needed, while only about 1% of accesses would need more than two -- assuming that a suitable hashing algorithm is used.

And there's plenty of room on today's disks. As of May 2010 when we checked, you could buy a 2-terabyte (2,000,000 megabyte) hard drive for about $150. To get up to a million different RepliCounts on that drive, we have 2 megabytes per account. If we want to keep the file at least 90% empty in order to increase the speed of the hashed access, we then have 200,000 bytes per RepliCount. That should be more than generous enough for most uses. So it's possible to manage a million different RepliCounts efficiently even with minimal hardware.

Note the two hashing operations. The first is used for security -- so that even if a copy of the whole database at the RepliCounts server were stolen, no one could use that copy to log into peoples' live accounts. To assure this, the actual secret account name (sent from the owner to the server by SSL or other secure channel) is immediately hashed into an encrypted version, using a one-way hash, a procedure that nobody knows how to reverse. Then the server securely deletes the actual account number (leaving the owner's copy as the only one in the universe, unless the owner has carelessly let it out), and uses the hashed version as a stand-in for processing that account. (We will later outline a hierarchical password system that can cleanly recover the account, even if the only copy of the account name is lost, wiped out, stolen and misused, or otherwise compromised.)

Note: Recently security experts found an unexpected flaw in a hashing procedure widely used for credit cards, but reported that it did not compromise security. Two different bankcard numbers might hash to the same result. But the loss of security was insignificant, apparently because the card number that came into use first would remain in use, but when the system tried to assign the second card number that had the same hashed result, it would look like the card number was already in use, and therefore the software would generate another number for that reason. In no case could two bankcards in actual use hash to the same result. Since bankcards have 16 digits, and RepliCount names can have much more variation, this kind of security flaw could have more impact for RepliCounts. Still we doubt that it will be an important problem -- and there are plenty of workarounds if it is.

The second hash is not for security, but happens when the server needs to read or write to the Accounts file. The stand-in account number resulting from the first hash is hashed again in a different way, to spread the account names more or less evenly over the disk space. This second hash does not involve encryption, and different accounts going to the same disk address is only an efficiency issue, and usually a minor one.

The Owner's Dashboard

An account will begin its life with a name (either random, or suggested by its owner as described above) -- and various settings inherited from its parent account. An account's owner can examine most of these settings, change most of them, withdraw or add money, etc., through the owner's dashboard for that account. To reach this dashboard, the owner visits the home page of the RepliCounts server and types or pastes the secret account number into a box provided for this purpose; the account number is transmitted to the server using SSL or other security, and authenticates the owner to use the dashboard for the current session.

The dashboard displays the account status and offers the owner various allowed options and other capabilities. There could be hundreds of these, even thousands, so they must be arranged in logical groups. For example, with the amount of money in the account will be a box to enter an amount to be withdrawn -- which might be done by the account mailing a check to a default owner's address that had been set up elsewhere on the dashboard. (The owner's address for receiving the check could even be irrevocable, since the owner has other ways to close the account and receive money, in case the owner moved, or the irrevocable address otherwise became inaccessible.)

If the account is used for mass sponsorship of music, a new band might have obtained the account from another band, which removed its own information before selling or giving away the empty account. So the account owner (the new band) would start with a RepliCount generally set up for a band, and make any needed changes, including entering its own information: promotional material, the owner's address (where the checks are mailed, above), perhaps some additional security options. The band's songs or other content will not need to be uploaded to this master RepliCount, that each song will be managed in a public-account offspring of the master account. After the setup, the owner (the band) will seldom need to go back to the master account's dashboard except in an emergency, so the account can be kept securely, maybe in a safe-deposit box or an office safe.

The owner's dashboard of the band's main RepliCount will not manage individual songs, because this will be done in public accounts -- usually a separate account for each song distributed by selling mass sponsorships. However, the master-account's dashboard can set up private access to each of the owner's dashboards of the various public accounts that are offspring of the master. Therefore the band can give different people exclusive access to manage particular songs -- and take back that access if ever required.

Public Dashboard

We mentioned public accounts above. Their names are not secret (or only slightly so -- such as an account given to a college class for access to premium content), and are usually intended to be shared, even publicly. The public (anyone who has the account name) will reach a simple public dashboard -- usually by just clicking a smart URL in the form www.automatic-accounts.com/public-account-name (or alternatively by visiting the website of the RepliCounts server and pasting the public account name into the same box account owners use to reach their owners' dashboards).

We think that the most common use of RepliCounts will be to download free (sponsored) music, videos, articles, or other content. In this case, the public dashboard might show a big green button to click if any sponsored downloads are available. Other likely contents of this dashboard will be a smaller button for a free sample (always available, regardless of sponsorship status, if the artist or other content owner decides to offer it), and an online form for purchasing additional sponsorships of that same content, paying by bankcard, PayPal, etc.

Account Transactions

In order to pay any money, non-public RepliCounts must receive the secret account name to authorize payment. The account owner at the dashboard has already entered this secret name, and therefore can use the account to pay money. A public account can never pay any money, except automatically to its owner, through its parent account.

In practice, we don't expect much use of RepliCounts as an alternative to PayPal, etc. (for a buyer to pay a seller for goods, or to transfer money from one party to another. Existing payment systems already handle this process well. Such transactions might even be blocked by the server for legal reasons, especially the hassle of registering as a money-transfer service in many different jurisdictions. Instead, a typical transaction might be: downloading a song or video free (but only if sponsorship is available at that moment, and charging the sponsorship maybe 20 cents, or a dollar, or any other price set by the artist(s) for the content); paying 5 cents to send an email, with the money going to the recipient, for spam control; paying $60 to a consultant for a small, quick job online, if the consultant accepts the work; donating to a charity, where a RepliCount (and its public-account offsprings) help to structure the campaign, providing payment processing, accounting, security features, transparency, instant use of funds in an emergency like a natural disaster, recognition to donors, recognition to fundraisers, and sometimes even organizing the fundraising campaign into a competitive team game. The advantage of RepliCounts is that lots of stuff that works can be inherited automatically, from one project to the next.

In addition, the simple dashboards of public accounts can easily function in each user's choice of dozens of different languages that are supported by the particular RepliCounts server -- making global audiences and funding campaigns much easier, even without use of machine translation (which could of course also be available for other uses, such as translating a text article, or a sponsor's personal message). Once a smart URL is set to a different language, it and all later copies of it will remain in that language until somebody changes particular copies to some other language.

The advantages over conventional payment systems are obvious, especially since most of the know-how (such as accepting many different kinds of payment, communicating in different languages, or organizing a complex fundraising campaign) can be simply inherited from a previous successful case, by account replication. Lots of best practices can be packaged into an account as the default, but they be changed by each campaign if necessary for meeting special requirements. Such accounts will even evolve in normal community use, by natural human selection of the most useful and attractive accounts.

Scheduled or Time-Dependent Transactions

Most of what happens in an account results directly from a person's use of a dashboard (either the account owner's dashboard, or the public dashboard of a public RepliCount, to download a free (sponsored) song, for example. Note that only a single account is involved, in most cases. But other transactions will occur due to the passage of time. Examples are interest earned on the money in an account, possible actions contingent on financial or other news, or accounts that self-destruct on a given date, or after a certain period of non-use (a way to manage lost accounts, among other purposes).

These scheduled (or time-dependent) transactions could be handled by a sequential pass through all the accounts, maybe done once a day overnight, or at other intervals as required. Each account will be checked against a list of all possible time transactions provided anywhere in that particular RepliCounts system, and the transactions that apply will be executed (for example, to add one day's interest to the account).

More on Design and Internals

We may add to this section later.

For example, consider the design and internals of mass sponsorship. Here we'll just say that we are leaning toward the maximum length of a sponsor's message being 140 characters -- not primarily for compatibility with Twitter, but because Twitter has shown that this length works for people, for many purposes. We will also explain why we expect that few songs, videos, or other content will have more than five or ten sponsorships -- while a handful may have thousands or millions of them. We might discuss how to set up data structures accordingly. However, an experienced software engineer could find various ways to do this successfully, based on what we have said so far, so more explanation is not a priority.

Page updated 2010-06-18