Details about Login tokens

Remote login to networked services is often done with unsafe passwords and uncomfortable account names. Login tokens replace this system with a highly secure alternative, that makes login hardly noticable to the end user.

intro  details  questions  prepare  order

A Login token is a form of certificate that is installed on the client side of a seecure connection. For example, in a web browser that accesses websites over https:// URLs, but it works equally well for other protocols that are protected with TLS (formerly known as SSL), including secure pop3, secure imap, and secure ldap.

Authentication

If the web server decides that it requires authentication of the client accessing it, it can ask the browser to submit a Login token. This is usually because a protected part of the service is approached, such as a mail folder in a webmail application. Depending on the browser, it may ask for permission, and perhaps for a choice from a collection of available Login tokens.

The browser also has to prove ownership of the Login token, and to do so it receives an encrypted code that only the owner of the Login token can decrypt. After it receives the decrypted code back, the server is convinced of dealing with the proper client. The codes that travel over the network are different every time, so eavesdroppers have no use for codes that they might catch. This is far more secure than sending the same password over the network on each login; certainly when the same one is used on multiple sites. In addition, the codes generated during Login token authentication are much longer than passwords, making them even more reliable.

Public and secret keys

This mechanism uses a pair of keys that can reverse each others actions. What is encrypted with one key can be decrypted with the other. One key is stamped into the Login token and published along with it; the so-called public key. The other is kept secret, so that only the owner of the Login token has access to it; this is why that key is called the secret key or private key.

The secret key proves ownership of the Login token, and to make sure that not everybody can make that claim, there is usually a password or pincode on it to protect the secret keys. This password is only used locally, to gain access to the secret key. It is usually asked only once by the browser, namely the first time it needs to access the secret key after having started.

An important part of requesting a Login token is generating a new key pair. This is also a function performed by the browser. It keeps the secret key in an internal key store, protected with a password so it is not stored on the disk in a readable form. Or, when a supported smart card is attached, it may ask the card to generate the key pair and keep the private key stored on it. When done, the public key is sent to OpenFortress for inclusion in the Login token.

After the payment for the Login token has been received, OpenFortress places the order in the queue of tasks to be downloaded by a computer in a vault, in order to be checked, processed and signed with a secret key maintained by OpenFortress. This signature completes the certificate, because it can now be verified as a product of OpenFortress, and thus a product handled with the care that is spelled out in the policy for this product.

Installing a Login token

A Login token is installed as any other client certificate. When it has been constructed by OpenFortress, it can be downloaded from a particular URL. The browser will accept it, perhaps even silently, if the public key stamped into the Login token matches with a secret key stored internally. The Login token is then ready for immediate use.

The web browser should contain a preferences section where all certificates are listed; client certificates (or "your certificates") are usually listed separately, and after successful installation the new Login token should show up, named something like Anonymous User 12345 albeit with a different number. If you want to stop using it, you can simply delete it from this list.

The Login token is indirectly signed by the classical root certificate for TLS/SSL as it is used by OpenFortress. You must accept that before you can accept the Login token. This allows you to check that the Login token was indeed signed by OpenFortress, and that it was correctly done. Instructions for accepting this root certificate follow in the prepare-to-order checklist.

Use of a Login token

Decide what purposes your new Login token has, and particularly how secure you want it to be. Based on that, choose a suitably hard password. If you intend to base online banking on it, consider the use of a smart card that works with your browser.

You may find reasons to use more than one Login token in parallel. For example, one for protecting online banking based on a smart card, and another one without that smart card for easier access to other services. And perhaps another for work-related issues. You are welcome to use multiple Login tokens.

You may also see uses for multiple Login tokens with the same number on it; you can request such duplicates by renewing a Login token rather than requesting a fresh one. The renewed Login token, carrying the same number, can safely be treated as an equivalent of the original one by supporting web sites and other services. You may want to store the duplicate elsewhere, probably on another computer. This can be achieved with import/export (or backup/restore) functionality that browsers usually support for your own client certificates.

Login tokens expire after one year. Services that accept Login tokens for access should refuse access based on such expired Login tokens. OpenFortress however, allows one additional month of grace time for an (overdue) renewal of the Login token. The duplicate Login token can now be used to login on the service that refused access based on the expired Login token.

Resellers and cost

Login tokens are extremely low-cost, and if resellers charge more it will mainly be because of service. Expect the cheapest ones to start around EUR 1.50 or USD 1.50. Discounts may apply, depending on reseller. A cost comparison with an inhouse solution is available as a spreadsheet for Excell, OpenOffice or Gnumeric.

Paying the low amounts for single Login tokens is known as micro-payments; classical payment mechanisms such as bank accounts and credit cards are unsuitable for efficient handling of such payments. Expect resellers to use their own preferred currency, possibly through creative mechanisms such as your phone bill.

Resellers can pay OpenFortress in gold if they purchase single Login tokens every now and then. For more massive use it is possible to setup a specialised contract. Please contact us on sales@openfortress.nl for details.

Resellers may never be in the position to mount a so-called man-in-the-middle attack. For that reason, all key generation must be performed on the website of OpenFortress. The reseller can setup a temporary side-step to our website for that purpose, and return to their site after generation is done.