How to use LinOTP best and make it even more reliable

Lesezeit: 6 Minuten

There is always room for improvement after the initial setup of LinOTP. In this blog post we will show you how to optimize LinOTP and make it even more reliable!

1) Redundancy – have multiple LinOTP servers!

LinOTP is a crucial component of your authentication infrastructure. It must be resistant to failures and provide responsiveness. Both requirements are easy to achieve by having multiple LinOTP servers set up.

All LinOTP-related information is stored in a database of your choice. If the database technology supports several parallel clients, you should be running multiple LinOTP instances. All authentication operations performed and all configuration changes will then be known to each of the LinOTP servers due to the shared database. Of course the database should be redundant as well to avoid a single point of failure. 

The KeyIdentity Smart Virtual Appliance (SVA) supports High Availablity based on MySQL master-master replication out of the box. The redundancy is set up via a command line wizard:

appliance_configure -c setup_redundancy -p SECOND_APPLIANCE

Details can be found here.

2) Better safe than sorry – backup and restore!

Due to all data being stored in a database, it is quite easy to backup relevant information about tokens, UserIdResolvers, policies and so on. One way is to perform a database dump. Another – more convenient – possibility is to use the backup-restore facility provided by the KeyIdentity Smart Virtual Appliance (SVA). It can be accessed and configured via the Appliance GUI running at https://LINOTP:8443. The backup can be performed either manually or automatically by sending the backup to a remote backup server on a regular basis. Please keep in mind that although the backup is encrypted with a passphrase because it includes sensible data, it should be stored in a secure location.

You decide what the backup contains:

* Appliance configuration /etc
* Database encryption key
* SSL certificate and key
* Database

In addition to the database, important configurations of the operating system can be archived. This includes among other things the RADIUS clients and the network configuration – which becomes very handy in case of a disaster recovery involving a completely new LinOTP server. The disaster recovery procedure is described extensively here.

Due to security considerations, it is not recommended to include the database encryption key in every backup but to store it separately. This will create a regular backup useless to any attacker.

The recovery process is equally easy: selectively, the backup can either be restored during the initial setup of a new Smart Virtual Appliance or in a running SVA via the Appliance configuration GUI at https://LINOTP:8443.

3) Strengthen security – choose strong RADIUS passwords!

RADIUS is a proven, reliable and versatile protocol used in authentication contexts. But it has one major flaw: sensible information is encrypted with a static password shared between RADIUS client and RADIUS server. To minimize the security impact, you should:

* use a really strong shared secret
* change the secrets on a regular basis
* use RADIUS protocol via Internet only secured by an encrypted tunnel (like
* if possible: use different shared secrets for each client

Depending on the authentication client, avoiding RADIUS completely and performing authentication directly against the LinOTP API might be an option. Here are some examples for integrating LinOTP API in different programming languages.

4) Speed up LinOTP – enable UserIdResolver caching!

If deployed on a large scale, LinOTP’s performance can be affected by slow answering UserIdResolvers or a high number of UserIdResolver which need to be queried. Since version 2.9.1 of LinOTP provides optional caching mechanisms to speed up authentication and the self-service login, there are two types of caching which can be configured independently:

* Resolver Lookup Caching

This caches the information about which UserIdResolver a user belongs to. It will improve performance on setups, where many UserIdResolvers are joined into realms. If the user authenticates a second time LinOTP does not need to repeate the process with all UserIdResolvers to find the user but can directly access the correct UserIdResolver.

* User Lookup Caching

This is about the user’s attributes (like mobile number and objectGUID) and will speed up authentication as well as the self-service portal operations.

As usual caching means a decrease regarding the currentness of data. So, it is recommended to find a good trade-off between a generally fast user experience, possible security impacts due to using outdated data and single users not being able to log in anymore due to their data being outdated in the cache.

Documentation can be found here.

5) Each user has his own token!

LinOTP supports a great variety of token types, so you can and should determine which type of token fits different user groups best.

Possible criterias to consider:

* Security

Not all users perform equally security sensitive tasks. So, for example it can be wise to outfit administrators with hardware tokens, while normal users get their OTPs via SMS.

* Handling/Convenience

Comfortable handling is a critical factor for the acceptance of MFA by users. Hardware tokens are very secure but for some users it might for example be difficult to read and enter the OTPs or – like for YubiKeys – there might be no USB slot on the machine to put in the tokens. For such users different types of token are more suitable. For example, SMS and voice tokens are a good choice. The KeyIdentity Push Token adds an additional layer of security to the convenient usage by working on the basis of transactions.

* Deployment/Rollout

It is important to consider the effort required to equip users with tokens. Of course, it would be most secure to hand over a hardware token personally – but this is often no acceptable option, e. g. if the user base is spread across the world. It might be better to use soft tokens (like OATH or Push), which can be rolled out by the users themselves via the self-service portal. Another option would be SMS or email tokens, which can be automatically rolled out the first time a user logs in – no further interaction is required by administrator, help desk or the users.

* Reliability

Some types of tokens require more infrastructure than others. For example, SMS tokens will only work if the SMS provider is operating correctly. The more components involved, the higher the probability of failure. This gets even worse if parts of the infrastructure can not be controlled directly. A good example are SMS tokens again. They are easy to roll out and very convenient for the users, but not reliable in some parts of the world due to difficulties of relying on local telecommunication providers. So despite all benefits, SMS tokens can be rendered useless because of the geographical situation of the user.

* Costs

Tokens can either cause acquisition/replacement costs (e. g. hardware tokens) or costs due to usage (voice tokens, SMS tokens). It is therefore useful to consider the expected frequency of use.

Find the balance!

So, it can be concluded that it is worthwhile to invest some time to define which groups of users can be distinguished, what their needs are regarding MFA and to evaluate which type of tokens fulfill those requirements best.

Detailed information about different types of tokens and their pros and cons can be found here.

6) Stay up to date!

In order to profit from new features, support for new types of tokens, and the most recent bug fixes, you should always run the most recent version of LinOTP. As a security product, LinOTP is developed to perform updates to newer versions quickly and reliably. But even if we do our best to make the update process as painless as possible, the proven administrator standards apply: Make use of testing and staging environments and always have a plan for a rollback.

With that in mind, the update is pretty straightforward using the means provided by your operating system. LinOTP will take care of anything else – no need for manual intervention. In a redundant setup, it is even possible to update one node first, check functionality and then upgrade the other server if everything looks good on the first one.

The KeyIdentity Smart Virtual Appliance provides a configuration module via the Appliance Configuration GUI to plan automatic updates on a regular basis.

This will take care of LinOTP and keep the operating system updated as well. If you need to put LinOTP on hold for any reason, the command line on the KeyIdentity Smart Virtual Appliance can be used. Log in to the SVA and enter the unrestricted mode:


Set LinOTP (and FreeRADIUS if desired) to not be updated:

>apt-mark hold ‘^linotp’ ‘^freeradius’

The update can now be performed immediately via the command line:


To list the status of packages held back and to undo the locking, the following commands can be used:

>dpkg –get-selections | grep hold apt-mark unhold ‘^linotp’ ‘^freeradius

And if you want to catch up on our latest security updates book our Blog as RSS-Feed!

Von |2018-02-28T18:58:42+01:0028. Februar, 2018 um 18:58 Uhr|KEYIDENTITY, LINOTP|Noch keine Kommentare

Über den Autor:

Mirko Ahnert