|
|
|
AxiomaticTokenizerAction authentication tokens
|
|
|
|
|
|
If the online payment service that you use accepts one-time tokens, you can use AxiomaticTokenizer to generate your tokens. You can read here how it works.
Newest versionThe newest version is 3.4.6.0, released on 15.10.2008. You can download it on your computer by right-clicking here and choosing "Save link as". Then just click on that file to open it in your web-browser and use it. SHA160: 6A1A 5FDB C3E0 B66A 4EC6 8BBF 6D03 122E 0FA6 623D (read what this is). AxiomaticTokenizer was successfully tested on:
FeaturesMulti-service support. Multi-currency support. Support for service partners. Support for sponsored entities. Support for payment delay. Support for inheritors. Support for group authentication. Support for payment arbitration. Support for subscriptions (/ repeated payments). The payment history can be hidden from all users. Actions specific for online payment services. Asymmetric encryption (RSA) for sending the shared secret (derived from the user's passphrase) to the service. Customizable token integrity code field size. This is meant to reduce the amount of characters which users need to type. Optional spy protection for tokens. The disadvantage of this protection is that it increases significantly the size of the tokens. Account name checksums meant to ensure that if the user types the wrong account name, he is warned about it. Users should publish their account names together with their checksums, like this "Alice/65". Private account names. By simply adding "#" at the end of an account name, the account name sent to the service is actually a mix of the written account name and of the service's name, in a way which effectively hides the written account name from the service. Color themes. Multi-language support. Table with mappings between two dice and characters. This is meant to help users to generate truly random passphrases. Multi-platform: Firefox, InternetExplorer, InternetExplorer Mobile, Opera, Opera Mobile, Safari. Easy to check HTML and JavaScript open source code.
Payment token exampleAT1; MTM; MP; 20080725173603; aliceakula.stash; bobbonkers.pub; NA; AUG; 10; U57 2KF R3E P8L T2Z;
ScopeAxiomatic tokens separate payments (and authentication in general) from the medium of communication, mainly the Internet. Axiomatic tokens are similar to bank checks, but they are unforgeable. It's easy to transfer a token through a service's web-forms, third party web-proxies, email, mail, phone, pieces of paper, SMS, and have the payments securely executed.
Service partnersService partners are entities which bring users to a service, and they receive a fraction of the payment fee charged by the service from these users. Service partners help a service grow faster. When you create an account with a service, you have the possibility to specify the account name of the service partner which recommended the service to you. If you do specify the account name of a service partner when you create an account, you will be charged a smaller fee for every payment you make from that account. Here is an example of how the payment fee could be split. The payment fee is 1% from the amount of paid digital currency. The following percentages are from the fee:
Only the entities chosen by the service may be service partners. This is so that the users, in general, could not be service partners for their own accounts.
Sponsored entitiesWhen you create an account with a service, you have the possibility to specify the account name of an entity which you want to sponsor. Every time you make a payment, the sponsored entity (automatically) receives a fraction of the fee which is charged from you by the service. If your account has no sponsored entity, the service gets the entire payment fee. Only the entities chosen by the service may be sponsored entities. This is so that the users, in general, could not be sponsored entities for their own accounts.
Payment delayIf you have an account whose name you make public, in order to enhance its security, all payments made from the account can in fact be made some time after you request the service to make them. This way, the account acts like a vault with a timed door, door which, for example, can't physically be opened during the night. For security reasons, once the payment delay is set, it can only be increased (not decreased).
InheritorsA user account may have inheritors. This is a feature which lets users specify to the service to automatically move all the digital currency from their accounts to the inheritor accounts, in case they become unable to access their own accounts. Let's consider that Alice, who has an account with the service, dies or becomes permanently incapacitated to access her account. Without inheritor accounts, it would be very difficult for Bob, her husband, and Claudia, her daughter, to receive the inherited digital currency. But if Bob and Claudia have an account with the same service, Alice can add Bob's and Claudia's accounts as inheritor accounts for her own account. If, during a period of (for example) one year (the actual value is set when an account is created), Alice doesn't send any valid token to the service, her account would enter in inheritance mode, that is, all the digital currency from her account would be automatically moved to the inheritor accounts, Bob's and Claudia's account. The way the digital currency is split depends on how many inheritance shares Alice allocated for each inheritor. The number of inheritance shares is specified when Alice adds an inheritor to her account. The digital currency is divided for each inheritor as a fraction equal with the number of inheritance shares allocated for the inheritor divided by the total number of inheritance shares allocated for all inheritors of that account. For example, if Bob has B inheritance shares, and Claudia has C inheritance shares, Bob receives a fraction equal with "B / (B + C)" from the digital currency in Alice's account, and Claudia receives a fraction equal with "C / (B + C)".
Cascading inheritanceThe automatic movement of the inherited digital currency from an account to the inheritor accounts has an interesting side effect: cascading inheritance. Let's say that Alice has Bob as inheritor, and Bob has Claudia as inheritor. If at some point both Alice and Bob become unable to access their accounts, Claudia will receive the digital currency from both of them, of course when each account enters into inheritance mode.
ArbitersWhenever you want to make a payment in order to buy something, you can use an arbiter to intermediate the transfer of digital currency. To do this, simply type the account name of the arbiter in the "Arbiter account name" edit-box from the "Make payment" page, in AxiomaticTokenizer. When you send the generated token to the service, the digital currency is taken out of your account and put in a queue which contains all arbitrated payments, from all users. At this point the digital currency is still owned by you, but is under the sole control of the service, and under contract that it will be sent to the account chosen by the arbiter. The arbiter can decide to either send the digital currency back to you or to send it to the recipient of the payment. The arbiter can not (physically) do anything else with the digital currency, like disappear with it (unless the arbiter and the recipient of your payment are the same entity). Note that if you use an arbiter, you may be charged an additional payment fee (the maximum fee depends on each service).
SubscriptionsSometimes you may want to subscribe to a service, or purchase something in installments, and have the periodic payments automatically made. You can use the "Setup subscription" action to setup a payment which will be made to same account name, for a specified amount of currency, for a number of times. The first payment is made when you setup the subscription, then repeatedly after the timeframe specified there elapses.
Group authenticationGroup authentication can be used by organizations to ensure that access to an account is possible only if a minimum number of members of the organization agree to execute the same action. For example, an organization might have an account with a payment service where it keeps (some of) its money. The organization would not want any single member to have full access to this account, but rather ensure that all payment requests are executed only if at least 3 (out of 5) members of the organization agree on the payment. When group authentication is used to execute an action, all members who generate tokens must type the same information in AxiomaticTokenizer (except, of course, their own passphrase). Then, they must send their tokens using a form (provided by the service) similar to this. The service checks if all tokens are valid for that account and ensures that all information from the tokens is the same, except for the time stamp and for the token integrity code. If all this is correct, the action is executed. Two members of a group can't have the same passphrase or shared secret. For security reasons, once an account is created, group authentication can't be changed.
SubtletyIt's very important that an action to be executed is authenticated by the exact required number of present members, not by more. Consider that an account has group authentication set to "3 / 9" (3 out of 9). If a payment is being made and all 9 members generate tokens for the payment request, an attacker who could intercept the token submit form could split the 9 tokens in 3 sets, and then send them to the service as separate payment requests. Since the tokens don't have a way to identify that they refer to the same unique action, the service can't tell that all 3 sets do in fact refer to the same unique payment and it would execute execute all 3 payments. The token time stamp could be used as a way to identify the same unique action for any number of tokens, however that would require that all group members synchronize it so that the service could mandate that it too be the same for all the tokens of the group sent in the same token submit form.
Show payment historyPeople will always need a public account where to receive digital currency, but they also need an account which can be hidden from anyone else; "hidden" doesn't mean hidden from the service, but from other people. The problem is how to transfer currency from the public account to the hidden account, without other people ever knowing of the transfer. This is solved, by the service, by not keeping the history for all the payments into and out of the public account. In order allow this, AxiomaticTokenizer lets users specify whether to keep or not the history of all the payments for an account. For security reasons, this can be only specified when an account is created, or changed later from "Yes" to "No" (never from "No" to "Yes"). Even if the user chooses to not keep the history of the payments, the service may still keep it internally, but it's guaranteed that no other user will see it. This feature isn't useful for organizations who need to keep track of the payments they receive and make, but they can use delayed payments and group authentication anyway. Individuals may find this feature to be the only one to protect them from criminals who would want to see what currency they have in their accounts, how much currency has entered into the accounts and to what accounts was the currency moved.
Known issuesFrom Opera 9.5, this isn't an issue anymore. Opera 9.24 and Opera Mobile 8.65 don't visually update the combo-box items which are automatically selected. From Firefox 3, this isn't an issue anymore. Firefox sometimes doesn't activate the function to copy text (from outside a text-box) to clipboard. If this happens, first select some text from a text-box, then select and copy the text of a token. InternetExplorer 8 beta 2 doesn't properly handler UNIX style line breaks, so AxiomaticTokenizer may fail to load (depending on what text editor was used).
In order to properly see the integrated keyboard and the "Dice – character mappings" table on InternetExplorer Mobile, the "Menu \ View \ One column" setting must not be set.
History of changesVersion 3.4.6 (coming soon) Added a service action to generate the hash of a service's data.
Version 3.4.4.5 Textual hashes are in general represented in radix 32.
Version 3.4.4.4 The service internal name is now a service seed. Certain hashes (for example those for the passphrase blender and for the token integrity codes) are now MACs. In theory, this is not necessary because the tokens have a fixed format, but just in case.
Version 3.4.4.2 Added Execution warning proof.
Version 3.4.4 All tokens have a service ID field to help with automatic processing. The token submit form can now automatically select the processing weblink.
Version 3.4.3.8 Improved integrated keyboard.
Version 3.4.3.6 The Execution proof is usable for all tokens.
Version 3.4.3 Added custom settings. Cookies are saved on Opera Mobile.
Version 3.4.2 Added a service action to generate account locators from account names.
Version 3.4.1 Sensitive data can be manually cleared by clicking on the header or the footer of the program's page. It is not automatically cleared after some time of inactivity because mobile devices would be in suspended mode by then.
Version 3.4 Added Show payment history. The action to change the settings of an account was split to one for each settings.
Version 3.3 Added Group authentication.
Version 3.2.0.1 Fixed a validation bug for the sponsored entity. Replaced some "eval" with function pointers. The minimum size for account names is 12 characters. This minimizes the possibility of using brand names as account names, which in turn minimizes potential legal requirements for the service to police such account names.
Version 3.2 Added Execution proof.
Version 3.1.1 The integrated keyboard can be used in InternetExplorer.
Version 3.1 Added the "Setup subscription" action.
Version 3.0 The payment delay can be changed, but only increased. While a token is generated, the user sees a waiting page. Added a third weblink for the token submit form. Support for Opera Mobile.
Version 2.9 Added payment delay support.
Version 2.8 Added support for Sponsored entities. The "Modify account" action has been split in two: "Modify account" and "Change passphrase". The "Modify account" action allows the user to modify information, like the service partner account name.
Version 2.7 Added account name management. Users can easily recall a previously used account name, and fill in with it an account name form field.
Version 2.6.4 The color of the weblinks from the help is now the one from the current color theme.
Version 2.6.3 Service action and currency name groups have been replaced with arrays.
Version 2.6.2 When a token is generated, the weblink where the token must be typed is displayed. A backup weblink is allowed in order to mitigate DDOS attacks.
Version 2.6.1 When a "Make payment" token is generated, its associated payment reference code is displayed.
Version 2.6 The user fills in the data field by field, as in a wizard.
Version 2.5.4 Added support for service partners. Fixed a passphrase comparison bug.
Version 2.5.3.2 Added a link at the beginning of the help page for going back to the welcome page.
Version 2.5.3.1 Links now have the color specified in the theme.
Version 2.5.3 Added support for arbiters.
Version 2.5.2 The account names can now contain a checksum. If the checksum is invalid, a message is displayed. Added the "Dark Gray" color theme.
Version 2.5.1 Added support for the passphrase blender. |
|
|
|
|
|
|
|
|