Action authentication tokens
The source code of AxiomaticTokenizer is released under a Common Sense License.
If the online payment service that you use accepts one-time tokens, you can use AxiomaticTokenizer to generate your tokens.
The newest version is 220.127.116.11, released on 31.01.2011.
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.
AxiomaticTokenizer was successfully tested on:
Axiomatic 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.
Support for service partners, sponsored entities, inheritors, group authentication, payment delay, payment arbitration, subscriptions (/ repeated payments).
The payment history can be hidden from all users.
Account ownership can be reclaimed if the service's database is compromised.
Actions specific for online payment services. Service administration actions are included.
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".
Secret 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.
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.
Payment token example
AT1; MTM; MP; 20081122115157; aliceakula.pub; bobbonkers.pub; NA; AUG; 10; DET YYM CLR 8G4 SJ5 C9G;
The security of online payments is today under heavy attack and things are only getting worse as more and more people start making payments over the Internet. Threats like spyware and phishing destroy user confidence in online services who are expected to "do something".
Consider the classical way of making an online payment: a user creates an account with a service provider, and he authenticates himself into his account with the account name and a password. The problem here is that the computer which sends the password to the service could be infected with spyware, spyware which could intercept and send the password to a thief who could later log in the user's account and steal all the digital currency.
This problem could be solved with a dedicated portable device which can access the Internet, device which would not allow users to install and run other applications. Such a device could not, in theory, contain spyware. But software is buggy and it can never be trusted 100%, particularly not when the amount of code required to make such a device work is huge.
But there is another way, way which is critical for the user who means business, the user who manages a lot of digital currency online. By separating the authentication process from the communication process, maximum security is reached.
The dedicated device no longer needs to be connected to the Internet, it simply has to produce the authentication information which the user can send to the service together with the request to execute a certain action in his name / account.
The problem of of such old devices was that they were generating a token which was not dependent on the payment information and could therefore be used to authenticate whatever information left a computer infected with spyware and malware, information which could be different from the one typed by the user into his web-browser (because it can be modified by malware, on-the fly; see Banking in Silence). This kind of attack on user information is known as a man-in-the-browser attack.
For this mechanism to be truly safe, the tokens must depend on the payment information. The process is straight forward. The user types into the device all the information which is necessary to make a payment. Then, the device generates a token, a text which the user can type into a web-browser on a computer which is connected to the Internet.
Currently, there are such devices on the market, for example Digipass 261.
Tokens authenticate every action made by the owner of the account, instead of just the login (as is with passwords).
Every token is unique, and is created in a deterministic way using cryptographic operations (hashing), so someone who intercepts it can NOT use it (again) to make a different payment, like they can in the case of passwords.
A token is generated from the data which has to be sent to the service (like the account name of the user, the account name of the recipient of the payment, the amount of currency to be paid), some dynamic data (like the current time) which makes the token different every time, and a secret, called shared secret, which is known to both the user and the service. The shared secret is generated from the user's passphrase.
A token is like a one-time password. It can be used to secure data only one time. After it is used, it must be discarded, else it could be used to perform the same action again. The difference between a token and a one-time password is that a token secures the data which has to be sent from the user to the service, whereas a password is simply used for comparison.
The service verifies that the action requested by the user was indeed initiated by him, by using the payment information from the token sent by the user, to generate a token in the same way. If the two tokens are the same, only the owner of the account could have sent the user token, so the service can confidently execute the requested action.
The one thing which makes it impossible for anyone, other than the user who owns the account and for the service, to generate the correct token is the shared secret.
The shared secret is sent by the user to the service, when the user account is created, also using cryptographic operations (asymmetric encryption), in a way which makes it impossible for anyone to decipher it. After this, the shared secret is never sent to the service, like passwords are, but only used to generate tokens, by both the user and by the service. The way tokens are generated makes it impossible for anyone to extract the user's passphrase or the shared secret.
A token contains the plain data which the service has to know in order to re-create the token on its own, and a hash of this data. If the user token and the service token are the same, it means that the shared secret which was used by the user to generate his token is the same as the shared secret from the user's account. Thusly, the user and his action are authenticated and the action requested by the token is executed.
A simple solution
The original intent was to develop a complex solution, using full asymmetric cryptography (encryption and signatures), which would cover all technical sides of an online transaction (not necessarily a payment). The problem of such a solution is that it's just too complex for generalized use.
A major win for this simplified solution is that users only need to know their passphrase. A single passphrase is enough for all services and accounts, because the shared secret is not the passphrase itself, but a hash of it, and therefore no service can know the shared secret for any other service or account. Users don't need to store key pairs, signed documents, encrypted documents, documents which need to be backed-up, documents which could be lost (and digital currency along them) or forcefully revealed to thieves.
For users, AxiomaticTokenizer provides a simple, standardized user interface for making secure payments. For service providers, integration with the token standard is simple and can be done with ease. In fact, since AxiomaticTokenizer is released into the public domain, it can be modify in any way to fit the requirements of each service.
Simplicity, standardization of user interface and safety are the key features which make AxiomaticTokenizer the ideal solution for the generalized use of highly secure payments online.
Who should use it?
Password-based security is extremely simple, so why would a user trade this simplicity for token-based security which require some effort to type the tokens?
Users who only have several hundreds dollars worth of digital currency in their accounts, have no reason to do this. However, the necessity to protect large amounts of digital currency, starting from (tens of) thousands of dollars worth of digital currency, motivates users enough to deal with token-based security.
Service 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.
When 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.
If 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).
A 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)".
The 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.
Whenever 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).
Sometimes 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.
The service may allow the users to change the amount of currency to pay for the next installment, but only if the amount is smaller than the initial amount.
Group 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.
All actions, except "Change passphrase" / "Claim compromised account" and "Login account", are affected.
The token submission form of a service (which has support for group authentication) must provide a way to show enough edit-boxes where the tokens of the members of the user organization may be typed.
When an account is created, the number of tokens typed in the token submission form must be equal with the total number of members of the group, number specified in the "Create account" token (of each member). The account can be considered owned by the group only if all the group members receive back from the service their "Success" or "LastExecuted" execution proof, else the account name must be discarded.
In the case of all other actions (affected by group authentication), the number of tokens must be equal with the required number of present members; otherwise, the action is not executed.
For all the actions affected by group authentication, the execution proof is independent for each member of the group.
It'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.
People 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.
What happens if a service experiences a security breach and all the shared secrets of its users become accessible to thieves?
AxiomaticTokenizer includes a mechanism for recovering from such events.
Here are the step which must be taken by the service:
Users can now reclaim the ownership of their accounts by using the "Claim compromised account" action.
In order for the service to be sure that the passphrase of an account is indeed changed by its actual owner, and not by a thief who has access to the shared secrets, the token which is used to claim a compromised account contains the pre-hash of the current shared secret. The service must check that the hash of the received pre-hash is the same as the current shared secret.
Administrative actions may be executed only by certain users and deeply affect the functioning of the service. See this for the available administrative actions.
Any user can generate tokens for administrative actions (using AxiomaticTokenizer), but in order for such a token to be executed by the service, the account in whose name the token is being executed must be allowed to perform the requested action.
Administrative actions may be associated to any existing account, for instance by using the service's management software or by using "Change admin actions" tokens.
DO NOT associate administrative actions to an account before it's created, because someone else might create the account before the intended entity, and thus gain administrative privileges.
Tokens may be asymmetrically encrypted with the public RSA key, included in AxiomaticTokenizer, of the service where the token is to be sent.
Encrypted tokens may be sent through unencrypted communication channels, without revealing their content.
The tokens for creating an account, for changing the account's passphrase and for claiming a compromised account are (and must) always be encrypted.
All other tokens may be unencrypted (although they can also be encrypted), and this is preferred for the following reasons:
AxiomaticTokenizer automatically computes, and displays to the user, a number of texts called "execution proof", for all tokens.
An execution proof is computed in a unique way, from all the token fields (which are used to compute the token integrity code).
The service must always compute and include an execution proof in the response sent to the user, so long as the token's integrity could be verified. If the token's integrity can't be verified, like when it is malformed, no execution proof must be sent to the user.
For all the actions affected by group authentication, the execution proof is independent for each member of the group.
An execution proof may not be sent if the token is queued for later execution.
The user can then compare the execution proof sent by the service with one displayed by AxiomaticTokenizer. If there is a match, it means that the service guarantees to the user the what the execution proof means has indeed happened.
Types of execution proof
Conditions must be evaluated in the order presented here.
"Success": This must be sent only if the requested action was successfully executed.
"LastExecuted": This must be sent only if the token is identical with the last successfully executed token.
"Expired": This must be sent only if time stamp of the token is smaller than the time stamp of the last successfully executed token, or if it's bigger than the current time with 5 minutes (this margin of error is for cases when clocks are desynchronized). This must not be sent if the "LastExecuted" execution proof should be sent.
"Error": This must be sent in any other case. If a "Create account" token can't create the requested account, the service has to send this execution error proof.
Without execution proofs, the account creation phase would be exposed to potential MITM (= Man-In-The-Middle) attacks, if the attacker could intercept all the Internet traffic of the user who wants to create an account.
To do this, the attacker would have to intercept the original "Create account" token and not forward it to the service. As such, the service would not have an account with the name specified in the token, and so nobody could make payments to it.
Later, when the user would try to access his account, he would likely do it with an unencrypted token, token which would expose the account's name. At this point the attacker would intercept the user's token and send to the service a (shadow) token in order to create the account with the name specified by the user, but with a shared secret known by the attacker.
From this moment on, the attacker would in fact own the account with that name, without anyone's knowledge. At least until he could no longer replace the user's tokens with his own (shadow) tokens, like when the user would use another computer to connect to the Internet.
To prevent this, the user must compare the execution proof sent by the service with the ones displayed by AxiomaticTokenizer.
Since the "Create account" token is encrypted and only the service can decrypt it, nobody else can compute the execution proofs. So, if the service sends back to the user the "Success" execution proof , the user can be sure that his token was indeed processed by the service, and that the account with the name chosen by him is accessible only with his shared secret.
All the other types of tokens are intrinsically secure against MITM attacks, so for them the execution proofs provides only assurance that the token was processed by the service and it wasn't stopped on its way by an attacker (who then sent back to the user a response as if it's coming from the service).
AxiomaticTokenizer can process signed documents. Besides verifying signatures, it may also perform further processing, like importing service information (this feature is not implemented yet).
See this for technical details.
********** Begin AxiomaticTokenizer Document **********
AEB 00F 2B4 25A DD2 F15 A77 83B 060 553 D23 25C 623 7A7 AA8 5A6 ED9 BA3 FFD E60 ABF B
------------------- Begin signature -------------------
Salt=C8F 5CF E3F 62C 0D2 CA0 B6;
Value=01B A5E 3F3 E76 8D2 BCE C92 E0F BA9 CAF 59C 7A9 80D 91F 9B7 0AF 35F 045 5A8 C51 85A 64D D9D 30C 748 25E 63D 425 9E8 377 ACA E2A 6CE FFA 269 69C 09C 1FD E47 B24 8B2 C97 1A9 CB3 67A FCD C82 2FF B68 23E A17 144 AF2 366 0DA DF2 706 480 A92 498 D44 06B F63 67E 9CC 3E9 8CB 804 652 00B 073 030 40F 6C1 8E7 6CE 79A 717 D6B EBC 15A 918 845 425 5E8 20E 352 835 897 FB7 F1A 646 FC1 603 82B 856 BEB E6A E90 A45 94F E64 8C1 83A A72 E9F 5EA C7B 098 A40 1B4 CDF 41C 381 995 BBE E5E A7D 874 5DF 0B4 6BC 80D 00E E23 14E EC9 01E 74A 1F9 47B F62 BEF 957 868 028 0A6 F18 B2F 78E 5FA 431 CB8 1D8 851 D32 CEB 755 CA6 FAA 20C BAD 71D 2BC 721 C84 CEA EE7 F71 6B3 7B8 0E7 ADC A7D 5A1 531 149 54C DDC 0BA 0D;
*********** End AxiomaticTokenizer Document ***********
Services can use this HTML page as their token submit form, where users can type their generated tokens.
Services can customize it to fit their specific requirements.
Although this form can be made to work offline so that the users could simply type tokens in it, this would mean lost flexibility for service providers.
A service may want to give to its users the possibility to download and use the original AxiomaticTokenizer, but with some customized internal values, like the default language and color scheme.
Since AxiomaticTokenizer can't be changed, it means that only its file name may be changed. The file name may contain custom settings in the form "name=value", all separated by "_" (including the first one). Some custom settings may be lists, in which case the items of the list are separated by ",".
AxiomaticTokenizer parses the name of the file form where it is started and changes some internal values to match those specified.
Here is the list of possible custom settings:
If a custom setting is not specified, the internal default value is used.
Here is an example of a file name which contains custom settings: "axiomatictokenizer _ clr=paleblue _ lng=ro _ vsid=MTM, FTM.htm" (ignore the blank spaces). When AxiomaticTokenizer is started from a file with this name, the initial color scheme is pale-blue, the initial language is Romanian, and the visible service names are only "Metal Money" and "Fiat Money".
From 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 handle 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.
Signed documents may be verified by AxiomaticTokenizer. Go to "Help" and then to "Verify document signature" in order to start the wizard.
Added the infrastructure for the verification of digital signatures. In the future, a new service action will allow users to verify the signatures of small texts signed by services.
Added the service administration actions. An item in the service actions combo-box, "Show basic actions" / "Show admin actions", allows the user to switch between the basic and administrative actions.
The execution proofs are now generalized (= more may be added, if necessary) and are contained by a combo-box from which the user can select one to see its meaning.
Added a service action to recover a compromised service.
Added a service action to generate the hash of a service's data.
Textual hashes are in general represented in radix 32.
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.
All tokens have a service ID field to help with automatic processing. The token submit form can now automatically select the processing weblink.
Improved integrated keyboard.
The Execution proof is usable for all tokens.
Added custom settings.
Cookies are saved on Opera Mobile.
Added a service action to generate account locators from account names.
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.
Added Show payment history.
The action to change the settings of an account was split to one for each settings.
Added Group authentication.
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.
Added Execution proof.
The integrated keyboard can be used in InternetExplorer.
Added the "Setup subscription" action.
The payment delay can be changed, but only increased.
While a token is generated, the user sees a waiting page.
Support for Opera Mobile.
Added payment delay support.
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.
Added account name management. Users can easily recall a previously used account name, and fill in with it an account name form field.
The color of the weblinks from the help is now the one from the current color theme.
Service action and currency name groups have been replaced with arrays.
When a token is generated, the weblinks where the token may be typed is displayed. Backup weblinks are allowed in order to mitigate DDOS attacks.
When a "Make payment" token is generated, its associated payment reference code is displayed.
The user fills in the data field by field, as in a wizard.
Added support for service partners.
Fixed a passphrase comparison bug.
Added a link at the beginning of the help page for going back to the welcome page.
Links now have the color specified in the theme.
Added support for arbiters.
The account names can now contain a checksum. If the checksum is invalid, a message is displayed.
Added the "Dark Gray" color theme.
Added support for the passphrase blender.