IT security is on everyone’s lips today. But everyone understands something different about it: Pen-tests; secure coding or exploits; antivirus, antispam; data protection; still firewalls; security consulting; identity management; authentication. The subject of IT security is a broad spectrum. And that’s why everyone is also concerned with “IT security”. We deal with the special field of secure or strong authentication – multi-factor authentication.

The status quo of proprietary software and the market

IT security companies are often very specialized and therefore rather small companies. A few years ago this was even more true. Many important players in the market had fewer than a few hundred employees worldwide.

But because everyone was talking about IT security, the topic and thus these companies also became more attractive for larger companies and the merry-go-round of mergers and acquisitions picked up speed. Who still does know  Safeword Tokens? Secure Computing, Aladdin, SafeNet, Gemalto, Thales gave and give themselves a lively change of company names and product labels. Aladdin, SafeNet and Gemalto once had their own smartcard products and portfolios. These have now finally merged into Gemalto. 

In a merger, the company also grows its product portfolio. It is like after Christmas – new toys are coming, old ones have to leave the children’s room! And like this the grown company will also clean up its product portfolio. Products like SafeWord 2008, SAM Express and this year SafeNet Authentication Manager (the OTP part) will go end-of-life.

Death in a proprietary world

In the case of proprietary software, end-of-life often means the end of the software. If the manufacturer has licensed the software on a per-user basis, it is not possible for you as a customer to purchase even one additional user license for this software after End-of-Life! If you want to roll out second factors for new users in your company after the End-of-Life, then this is no longer possible. You have only licensed 1000 users? The 1000-and-first user can no longer receive a 2FA token in the old system! License exceeded!

Not only because of the missing support and the missing further development – No, even because of the missing functionality you are forced to migrate away from your existing system.

Manufacturers often offer supposedly attractive migration paths to the other proprietary product in their portfolio. But you know that migrations are expensive and time-consuming.

Pain point: Multi-Factor-Authentication

The migration of a multi-factor system comes with unwanted pain factors. Two-factor authentication usually means the combination of knowledge and some ownership. The ownership factor (Hardware token or a registered smartphone app…) is bound to the backend and simultaneously distributed to the user. Distributed in the field. Worldwide.

In extreme cases, the migration of an ownership factor can mean that the ownership factors distributed out there have to be collected and new ownership factors distributed.

Depending on the number of users, the structure of your company, the workflow of the users, this can be a lengthy, expensive and painful process – even if the new product comes from the same vendor. (It doesn’t come from the same manufacturer, but only from the same portfolio after the merger!)


Our employees have been working in the field of two-factor or multi-factor authentication since 2004 and therefore understand the pain of our customers. We have integrated this experience into privacyIDEA.

Already for some time privacyIDEA provides you with a smooth migration. Without any time pressure you run privacyIDEA and your old software in parallel, without the user having to notice anything about it. Step by step you roll out new tokens within privacyIDEA.

With the upcoming version 3.1 it will also be possible to import the seeds of old, existing tokens into privacyIDEA and automatically assign the tokens to the users and set the old token PIN automatically. No need to re-enroll tokens. Nothing to do for the users, minimal effort for the IT.

Many customers, such as Klinikum Hanau, already rely on privacyIDEA and have successfully migrated to privacyIDEA.

Look at the future

And if you want to migrate away from privacyIDEA? Why?

privacyIDEA is Open Source. With privacyIDEA you never meet the fate that you cannot roll out the 1000-and-first user. privacyIDEA is running. Will be running. Forever.

Invest in your future! Invest in Open Source! Invest in privacyIDEA!

Companies more and more rely on cloud services. As a result, the number of accounts and the amount of login data are growing rapidly. However, if the number of user names and passwords continues to climb, interfaces and security risks will increase. Single sign-on with privacyIDEA therefore offers the option of centrally managing an identity in order to ensure enhanced security and flexibility.

Single sign-on (SSO) is often misunderstood: The attribution “single” does not necessarily imply that the user only has to remember a single password – this is only partially true. In fact, SSO means that a user only has to log in once, but then still has access to several (cloud) applications at the same workstation – without further “logins”.

This is one of the reasons why companies like to use SSO for their own web services. The crucial factor, however, is not the reduction to one password – a central LDAP server would be sufficient for this – but the fact that users only login once. With SSO, companies offer their employees a central point of contact, whereby they can access all ERP, web or cloud applications they need for their (everyday) work with a single “login”.

According to Bitkom, 44% of all applications and work processes now run cloud-based (83% for large companies) and more and more cloud services are being used, so the need for single sign-on solutions is becoming more and more important. So here’s an overview, not just of the benefits of SSO, but also of what companies have to consider, if they want to use SSO securely and efficiently for their organization.

What is Single Sign-on (SSO)?

In particular, the growing demand for cloud applications is leading to an increased use of SSO. The reason for this is an obvious one: more applications (in the cloud) also mean more passwords or login data for different accounts. Single sign-on offers exactly this option: you only have to log on once, but then you are logged on to several applications.

How can a company benefit from SSO?

A single sign-on system, for example, reduces the proliferation of different accounts and passwords, which significantly increases ease of use for employees. They will most certainly prefer to remember one “master access” rather than many individual accesses.

In addition, too many accounts demonstrably worsen password hygiene, i.e. too many users often use the same passwords for different portals, which cannot benefit IT security.

Scattered “account silos” across multiple solutions – companies want to avoid this, not only because it is simply impractical, but also because it is insecure. With SSO, IT departments can easily create new user accounts centrally and even manage individual permissions. And if an employee leaves the company, “offboarding processes” can also be administered remotely.

Exactly this reduction to one credential – e.g. password and user name – minimizes the risk that access data is lost or consists of easily guessable passwords. On the contrary, if used correctly, SSO increases productivity, facilitates effective IT monitoring, and ultimately provides more control and security – while employees are granted or denied access to multiple systems, platforms, and other business-related resources with a single login.

How can SSO be used in the company?

However, in order to work properly, single sign-on services must access specific protocols. There are quite a few of these – for example SAML2, which is used intensively by Salesforce, or OpenID Connect (OIDC), which is also used by Google, for example.

SAML protocol

With a SAML protocol, the user receives an encrypted session cookie with which the user can authenticate to certain (cloud) services over a specified period of time. The big advantage is that the external service does not have to establish a connection to the internal authentication service (Identity Provider – IdP) – the connection to the user’s browser is all it takes.

OAuth2 with OpenID Connect

The OAuth2 protocol is used to authorize Google services such as Gmail or Google Drive. OpenID Connect is a further development of common protocols such as OpenID or SAML. Since it is generally regarded as simple and secure, OAuth2 with OpenID Connect is increasingly becoming the standard for authorizing API access on the web (and also for apps).

Users receive a unique access key which, in combination with the OAuth2 protocol, enables them to login. Information about the identity of the user as well as the authentication provided is returned to a client via an OpenID-specific token, also known as an ID token. The login then only applies to this one client.

Individual authorization processes – with Keycloak

However, since companies often have to meet different IT security and compliance requirements, they use so-called identity or access management systems – such as the open source solution Keycloak, which uses the two protocols mentioned above and is developed by JBoss under the direction of RedHat. So if role-based authorization does not meet internal needs, Keycloak offers adjustable authorization services.

This way, organizations can manage permissions for all their services through the Keycloak management console and have the ability to define exactly the policies they need.

The security issue – opportunity and hurdle at the same time

The fact that single sign-on systems fundamentally increase security is undisputed: they reduce the password jungle, prevent the creation of (account) silos, increase productivity and facilitate offboarding processes. But a large residual risk remains: A successful attack would always result in several applications being affected in one fell swoop.

But this hurdle can be overcome by additionally integrating a 2-factor authentication solution for SSO. With privacyIDEA as authproc filter (in simpleSAMLphp), for example, users can extend and individualize the authentication process in various ways. The first factor is authenticated against the authentication source (e.g. LDAP) and the second against privacyIDEA.

Functions, that Keycloak and privacyIDEA offer

With Keycloak you can log in with a second factor of privacyIDEA. The following functions allow a secure and user-friendly login:

Secure login with SSO

Exclusion of certain groups

Automatic token enrollment (if a user does not yet have a token)

Since privacyIDEA 3.0: Support of pushtokens

No input necessary: User confirmation via smartphone


The Single Sign-on concept has always been a big issue in many organizations. If companies today use common software and cloud solutions such as Office 365, Box or Slack, this does not mean that they need or want different passwords and login data for these services.

Especially in view of cultural subjects such as Bring your own device (BYOD) or the increasing number of decentralized workstations that can no longer be controlled by internal IT, the use of SSO is increasingly becoming a basic necessity in order to make traceable authentication processes secure and flexible.

We are proud to announce the release of privacyIDEA 3.0 today.

With privacyIDEA 3.0, we are setting the course for a stable future. While many users quickly lose themselves in tempting MFA SaaS offers, we want to continue to give our customers the opportunity to carry out their secure multi-factor authentication with a trustworthy system under their own control, on Premise. To keep it that way in the future, we have worked on several points over the past months. On the surface, they don’t seem to have a wow effect at first, but they give you as a corporate customer what counts for you: Long-term stability!

Python 3

privacyIDEA is written in Python. The Python version 2.7 will not be further developed after 2020. We have written the privacyIDEA 3.0 code to run on both Python 2.7 and Python 3.x. This gives you the confidence that you can switch from Python 2.7 to Python 3 without migration projects and that you can use privacyIDEA relaxed even after 2020. privacyIDEA 3.0 PIP installations can be run on Python 3. However, the Enterprise packages will still be delivered with Python 2.7 and will be changed to Python 3 in the coming months. For you there is nothing else to do except a normal update.

Crypto functions

Under the hood we also exchanged crypto libraries. The old library pycrypto had to give way to the de facto cryptography standard. Signatures and encrypted data now also have their own versioning, so that we are future-proof here if we want to change the way we sign or encrypt data.

Database Schema

We have broken with a design legacy that goes back to the first versions in 2009. Previously, the assignment of a token to the user in the database was stored in the token table itself. This was simple, but not flexible. The assignment is now stored in a separate table. This way we have already prepared the database so that several users can have the same token. This will make it easier for us to develop completely new token types in the future.

Installation variants

We have decided to deliver all installation variants as so-called Python virtualenv. This means in a dedicated directory privacyIDEA brings along all dependencies it needs. Thus in a given version of privacyIDEA always the complete same code will run. No matter if privacyIDEA runs on a Debian, Ubuntu, RHEL or SLES and was installed via pip, apt or yum. This helps to exclude side effects from underlying dependencies. The installations will become more homogeneous and stable. But you can still easily install and update using apt/aptitude or yum.

We will no longer build Ubuntu 14.04LTS packages of privacyIDEA 3.0 and later. But starting with version 3.0 we offer packages for Ubuntu 18.04LTS and 16.04LTS. The packages for Ubuntu can no longer be published in the PPA Launchpad repositories. Rather, we now publish them in a separate repository.

Installation of the new version privacyIDEA 3.0

privacyIDEA 3.0 is the Community Edition, which is available on the Python Package Index and in repositories for Ubuntu 16.04LTS and 18.04LTS.

The Enterprise Edition for enterprise customers will follow in a few weeks as version 3.0.1.

You can read more details on the privacyIDEA project page.

Before installation or update please read the online documentation and the READ_BEFORE_UPDATE.

Making wiring money secure is a big challenge. We are all grateful, that we no longer need to go to the bank institute for wiring money to another bank account. It is also great that we do not need to use these TAN lists anymore, when we were asked to cross out number by number after each bank transaction.

But what are still the challenges with electronic bank transactions?

Integrity of the transaction data

The banking user uses a web interface to tell the bank, how much money he wishes to send to another account. A malware in the user’s browser, can change this data. Originially the user wanted to send €100 to the account 1234567890, but when he clicked the button “send”, the malware changed the transaction data to €10000 and to the account 666.666.XX. The bank receives the 10000 Euros for the evil account. It has no chance to know, that originally the user wanted to send 100 Euros to his friend. Also the user does not immediately know what happened.

The money might be gone.

TAN lists and OTP tokens

The transaction data could be changed before they reach the bank.

Several years ago TAN lists were used. Some banks are using OTP tokens, to identify the user, during a transaction. But the TAN lists and the OTP tokens can not ensure the integrity of the transaction data. The OTP token can be used to verify that it is really the true user, who is in the possession of the token and who triggered the transaction. But still a man in the middle can intercept a valid transaction and change the amount and account! Still neither the bank nor the user know, that something happened in between.

This is due to the problem, that there is no cryptographic link between the transaction data and the OTP.

OCRA: Linking transation and TAN

The OATH Challenge Response Algorithm (OCRA) can provide this missing link. OCRA is specified in RFC 6287. 

Just like HOTP and TOTP – which you might know from the Google Authenticator – the OCRA algorithm is defined by the Initiative for Open Authentication. Basically OCRA is some kind of enhanced HOTP algorithm.

The HOTP algorithm takes only one parameter, the “counter”, which is increased continously by each key press. In conjunction with the secret key a 6 or 8 digit one time password is calculated. The secret key represents the possession factor. Thus the one time password depends on the secret key and the parameter “counter”. In case you like buzz words like HMAC and SHA, take a look at RFC4226).

To cut a long story short, OCRA simply enhances the “counter” and allows many more input parameters for roughly the same algorithm. I.e. you can also put the account number and the amount into the OCRA algorithm. This will result in a one time password, which depends on the secret key and the complete transaction data. If you or an attacker would put other transaction data (input parameters) into the algorithm, this would result in another OTP value.

How can this be used for online banking?

The bank initially hands over the secret key to the user. The key can be contained in a hardware device or in a smartphone app. The bank knows each secret key of each user.

The user enters his transaction data on the banking website. The user also transfers the transaction data to his device (which contains the secret key). This transfer could be done manually or in any automatic manner using QR codes, network or bluetooth.

On the device the user verifies the correctness of the transaction data. Only then he continues by generating the TAN on the device. He now can add this TAN in the banking website. The transaction data and the TAN is sent to the bank.

As mentioned earlier the TAN cryptographically depends on the transaction data. The bank can use the user’s secret key to also calculate the TAN for the given transaction data. If the bank gets the same TAN, the bank knows, that the user really was willing to perform this transaction and that the transaction data were not modified by an attacker. Otherwise the modified transaction data would result in a different TAN.

In this scenario each and every transaction which is issued by a bank customer is cryptographically secure. So it is more important to protect the secret key in the device than the online banking account itself, since there can be no transaction without the secret key.

privacyIDEA, OCRA and DisplayTAN

privacyIDEA supports OCRA (the TiQR token) for quite a while. In the upcoming version 2.20 the OCRA mechanism was enhanced, so that it can be used with many different devices, especially with the DisplayTAN-card.

Banks do not need to program the key management for their web application on their own to support OCRA. They can easily use one single REST API call with privacyIDEA to add strong transaction security with privacyIDEA.

The DisplayTAN cards are attractive for customers, since they can be integrated in the banking card itself. This way the customer can have on card for all tasks.

Just ask us!

This article was first published at owncloud.

Your Data is at risk. And thus is your personal life and your company’s values.
You avoid hackers, trade espionage and rogue governments getting your data by using your own cloud storage like ownCloud. Your data under your control.

But depending on where your storage is located some risks still remain. The connection to your ownCloud installation in the hosted datacenter is TLS protected. All data are encrypted on their transport to the datacenter. But within the datacenter your data is plain text.
You are using ownClouds integrated encryption? You even have the full disk encrypted using LUKS or similar methods? This is fine but only protects you from certain attacks like stealing the sole hard disk.
But if the attacker gains access to the very location where the actual encryption takes place, the encryption is useless, since this location also contains the encryption key! Thus, if the attacker has access to the datacenter or – more probably – is a rogue or bribed employee of the datacenter the attacker can get physical access to your encryption key and finally to your data.

This is why client side encrpytion is such a good idea. With client side encryption the data is encrypted on your own client. The key material is only available on your client, not on the ownCloud server. The data is sent already encrypted to the server. Not only is the transport layer encrypted using TLS but the payload itself within the TLS can not be read anymore.
The ownCloud server and the storage never sees any clear text data and never has access to the encryption key.
The tool cryptomator which was introduced in this[link] previous blog post works this way.


But enterprise scenarios come with a longer requirements list than tools like the slick cryptomater can cover.
Even smaller companies have to comply with the requirements of the enteprrises if they are supplier for the bigger ones.
I have run several projects where supplying companies were confronted with the requirements for encrpytion and two factor authentication since they delivered to bigger enterprises, that simple defined those requirements. Let us take a look at the requirements when you run a company or bigger organization.

File Encryption

In such scenarios when encrypting data it is important to encrypt files. In contrast to full disk encryption and encrypted containers encrypted files can be moved around without breaking the encryption. Even the encrypting file system does not provide this sticky encryption. If the user moves the file to another disk or a USB stick, the file would not be encrypted anymore, since with full disc encryption and container encryption the encryption is bound to the storage and not to the data.
The data should not be decrypted when the file is moved. This is why we require to encrypt the files and keep them encrypted when moving the file to another locatoin.

Client Side Encryption

As mentioned in the beginning the files should be encrypted and decrypted on the client. This way only encrypted data is transferred via the network. The user can also move the files as in the previous requirement but most important the encryption gets independent from the storage location.
The administrator can access the file but can not read the data in the file. This way all backup mechanisms still work, but the data is persistently protected.


When working with data in a company users are usually working on projects with other colleages.
Thus several users need access to the encrypted data. The project leader or data owner might need to add other users to the group and grant them access to the encrypted data or withdraw this access again.

It is important to note, that usually not *the* administrator gives access to the data. Complying to the concept of duty of separation, the administrator may be responsible for providing the storage and taking care of the backup, but he might not be allowed, to read the data and probalby will not be allowed to decide who is allowed to read the data.

This leads us to the requirement for a bit more sophisticated key management.

Key Management

If files are encrypted with passwords then a password based key derivation function (PBKDF) is used to generate the encryption key. A badly implemented encryption would use this key to encrypt the file. This would result in the problem, that – if you change the password – the complete file needs to be decrypted with the old password and re-encrypted with the new password. This might be fine for one small file but totally fails with a complete directory, a harddisk or a huge storage.

When you look at encryption a multi-step encryption has proven to be sensible. Even in the case of a PGP encrypted Email, the email is for many reasons not encrypted with the public key of the recipient directly but with a symmetric data encryption key (DEK), which is unique to this email.
Only this DEK is encrypted with the public key of the recipient. This is called Key Encryption Key (KEK).

The other great thing when using a DEK and KEK is, that several users can have access to the same data with different passwords – or different KEKs. This way a user who has access to the data can also be allowed to grant access on the data to a new user. The software can access the DEK with the KEK of the old user and encrypt the DEK of the file with the KEK of the new user.

This way, each file has a list of KEK-encrypted DEKs attached to it. Thus an enterprise encryption software needs to allow adding users with their key encryption key to files.
Users need to have different roles like adding users to access groups or only being allowed to access the data.

(Of course you can not effectively avoid the user breach: The user who has been granted access to the data can go rogue and print the data, take a photograph or copy. If you want to tackle with this threat you need to think about implementing data leakage prevenion.)

So what the heck with the KEK?

You might use the latest and greatest symmetric unbreakable encryption algorithms for actually encrypting the data. But these are of no use, if the access to this encryption – usually the password – is week. An attacker would always target the KEK (a.k.a. Passwords) and not the DEK (The encryption itself).

Thus, another important requirement is not only to encrypt the data but also to protect the access to this encryption. A good way to do this is not to use a password based access but to use public key cryptography.
As mentioned with the PGP example, the KEK is the public key of the user. The DEK is encrypted with the public key.
The user has to provide his private key to decrypt the DEK to access the data.

Perfectly the private key is located on a smartcard, so that the private key can not (easily) be copied or stolen.
If the private key was initially created on the smartcard, you can in addition be sure that the private key was not stolen or copied.

Data Read Escalation

As we required earlier the administrator usually can not read the data and can not add users to the group of data users, who can read the encrypted data.
But in certain cases – when all users have lost their smartcard, forgotten their passwords, have quit the job – the company needs to be able to access the encrypted data without one of the originial users available.

In this case the encryption solution needs to provide a process with preferably 4 eyes principle to regain access.
4 eyes principle is important to increase the trust and allow full deniability for all participants.

Technicaly the key management can to this by adding a system-KEK or recovery-KEK to all files.

Hardware Security Modules

Besides using smartcards for the user’s KEKs, the support for hardware security modules can be a good idea. The HSM can be used to protect the system-KEK or recovery-KEK or to sign configuration data. Otherwise a user with the right to only read encrypted data could escalate his rights to “assign-new-users to the encryption group” by flipping some bytes in the database.


We already said, that reencrypting the data is a bad idea and should be avoided. Nevertheless it can be necessary. E.g. if the symmetric encryption algorithm used to encrypt the files is know to have weeknesses. This is especially important if you need to upgrade the encrpytion algorithm.
In a worst case scenario the system- or backup-key could be compromized, then this keys need to be changed.
The solution should provide the possibility to reencrypt the data.

Possible Solutions

There is a quite nice long list of commercial products, which cover those requirements. Some are better and more convenient in smartcard support, some in group management and some in automation.
It is always a good idea, to identify your own needs and evaluate the right solution.
Most of the tools are products of companies located in Germany and thus comply to the (still) stirct data protection laws.

Why is there no open source?

Nevertheless there is no open source tool, which is capable of covering the requirements and competing with the commercial tools available. This might be due to the scratch-your-own-itch concept of open source development. Individuals start open source projects, which will provide a solution to their own problem. A perfect example is the tool cryptomator. It does a great job in file encryption and covers a lot of requirements but totally lacks the key management and because of this will only work for a single user, but not for project groups in a company.
Another reason might be, that the customers for such an enterprise file encryption tool in 95% of the cases runs Windows on their clients and may thus be used to install and use closed source software – so why should the software vendor bother about an open source busines model?

With the growing pressure of undemocratic survailance requests even by the German government the threat through backdoors and unpublished zero days increases dramatically. In a sensitive area like data encryption, where data obviously is to be protected from preying eyes, open source solutions can help to regain the trust in such software.
So I urge all open source companies with data storage centric products to think about enhancing their portfolio with an open source project for a trustyworthy, modern, enterprise ready file encryption solution. In my opinion this is not only a gap in the market but would also be a great help for a mature and democratic society.

ownCloud and privacyIDEA

privacyIDEA-800pxWith ownCloud 9.1 a new authentication framework for two factor authentication provider was introduced.

We implemented the privacyIDEA ownCloud App which connects ownCloud with privacyIDEA. This way you are able to use many different kinds of authentication devices like smartphones, key fob tokens, Smartdisplayer cards, Yubikeys for your users to authenticate at ownCloud. In addition users can use the very same centrally managed token to authenticate at other services like your VPN, Windows Desktop or SSH.


Use any authentication device with ownCloud.

This is a big improvement for your enterprise environment in contrast to only managing second factors within ownCloud.

ownCloud developers have done a great job on providing this 2FA API. Nevertheless while implementing the first external provider (the privacyIDEA ownCloud App) we realized some shortcomings of the API.

Working togeather with ownCloud to improve the Two Factor integration

I was able to work closely togeather with the ownCloud security specialist and the developers to discuss ideas and a strategy for improvements. Thanks a lot for this open mind and the time! We all (ownCloud and NetKnights) are eager to further improve the security and possible integration scenarios of ownCloud.

More information to the user

One idea was to improve the communication with an authentication backend like privacyIDEA. The current implementation only allowed to show “Authentication failed!” in case of an error. But using an external authentication system it sometimes can proove useful to display more information to the user, since authenticating with two factors is a more complex and error prone process. Also on the user side. Furthermore, displaying more information can be necessary when it comes to scenarios like challenge response.

Anyway, this resulted in an improvement of the 2FA API and a pull request to the ownCloud github repository which is planned to be contained in the next ownCloud release 9.2. This way the privacyIDEA ownCloud App can display additional information like “privacyIDEA Server down”, “Internal privacyIDEA Error”, “Wrong OTP value”… Thus the user could fix his problem (by using the correct token or flipping the token upside down…) instead of calling the helpdesk and causing additional costs.

Emails and SMS

Another topic, that was discussed, is the support for external challenge response like SMS, Email or TiQR tokens. While this is still work in progress the discussion showed, that great and sensible solutions and integrations can be achieved when combining ownCloud with privacyIDEA.

Go Secure

Secure your own data, your ownCloud with 2nd factor authentication under your control!

Get the privacyIDEA ownCloud App.

You may have read about the NIST, lately. NIST is updating its Digital Authentication Guideline.


NIST is the National Institute of Standards and Technologies. It is part of the Department of Commerce of the United States and works on standards which are met by several governmental institutions and and also companies. It is a physical laboratory and also deals with topics like earth quakes and fire protection. But also with standards in information technology. E.g., NIST played it’s role in defining the encryption protocols DES and AES.

Digital Authentication Guideline

Die Verwendung von SMS für Authentifizierung wird von NIST als veraltet eingestuft.

Die Verwendung von SMS für Authentifizierung wird von NIST als überholt eingestuft.

NIST now released a draft of its Digital Authentication Guideline. This guideline describes how to evaluate risks in authentication processes and also gives dedicated countermeasures and advices. Two factor authentication plays an important role.

The interesting and new part is, that the draft SP800-63B explicitly points out the risks of Out-Of-Band authentication using SMS (text messages). In section the usage of SMS is event denoted as deprecated!

OOB using SMS is deprecated, and may no longer be allowed in future releases of this guidance.

No authentication technology lasts forever

We do not want to start bashing SMS. But we should be very well aware, that no authentication technology is built for eternity or will withstand hackers forever. Technologies and processes we are using today may work very well – today. But tomorrow things may have changed and these technologies and processes may be easily bypassed by hackers.

The common conclusion should be: The used authentication technology or authentication process must be replacable. We should not rely on a product, that only implements one authentication process – in this case SMS. Because the effort if changing to another authentication process would mean changing the complete software. The complete backend. The vendor. Get a complete new solution.

Ever-lasting authentication with privacyIDEA

Due to this NetKnights relies on privacyIDEA. privacyIDEA is an authentication system, that supports a broad variety of tokens, authentication devices and thus authentication technologies and processes. Of course privacyIDEA supports one time passwords via SMS and Email. But it also supports one time passwords by smartphone apps, challenge response mechanisms, many different kind of OTP hardware devices, Yubikeys and also X.509 certificates and SSH keys.

A company which uses privacyIDEA has no problem with the NIST guideline. They can just enroll new token types for their users and smoothly change SMS tokens to smartphone apps, hardware tokens or Yubikeys. No software needs to be evaluated and replaced. No vendor needs to be contacted and no processes need to be changed.

This way privacyIDEA helps to reduce administrative costs and also reduces the TCO. NetKnights provides different level of service level agreemets for privacyIDEA. We also help with the integration of privacyIDEA into the company network and deliver the appropriate tokens.

Just ask us.



The German Open Source Business Award (also called OSBAR) is awarded by the  Open Source Business Alliance. The Open Source Business Alliance in a German association of companies providing and working with Open Source solutions with about 200 members. The OSBAR is looking for innovative open source projects and ideas which provide a crucial benefit to companies and institutions of the public sector.


We believe that the open source project privacyIDEA covers these requirements. Compared to ordinary or classical OTP systems, privacyIDEA implements a lot of new ideas and thus allows for elegant solutions in your network.

This is why NetKnights applied with the project privacyIDEA for the Open Source Business Award. You may read the German application. privacyIDEA_OSBAR_2016

privacyIDEA will provide an Event Handler Framework in the upcoming release 2.12.

Policies for Two Factor Authentication

Using policies you can already configure privacyIDEA in a very detailed and sophisticated manner. The administrator can define the behaviour of privacyIDEA. This way you can run privacyIDEA in many differenz scenarios and find a solution for all requirements. Policies change the authentication and authorization behaviour. The administrator can define security levels or perform an easy migration.


With the Event-Handler you get completely new possibilities. While policies change the behaviour of privacyIDEA, the Event-Handler does not change this, but starts completely new actions depending on events without changing the behaviour define by the policies.


event-handler-enThe screenshot above shows an event definition for the event “token_init”. This is the event of initializing or enrolling a token. In addition to the way the token is initialized, now the action “sendmail” is triggered. The logic is implemented in the handlermodule “UserNotification”. The interesting thing is, that such an action can be bound to any arbitrary event.


More Event-Handler-Module

The first event-handler module to be shipped is the module “UserNotification”. More modules are about to follow. A moduel “Enrollment” could trigger and action to enroll a certain token type for a user — as an reaction to any kind of event!

This way you get unimagined possibilities to design new, creative configurations and workflows. Once more privacyIDEA proves, that it is a modern, innovative and trend-setting authentication system.

Please sign up to our newsletter to always be up to date.

Easy migration of an existing OTP system to privacyIDEA

Often customers decide to switch their existing, proprietary OTP / two factor authentication system. They do it for several reasons. The existing system is to old and they get no useful updates anymore. Often the existing system is not flexible enough. The tokens, which run with this system, do not comply with the todays requirements. Companies merge and each company comes with its own proprietary authentication system. Sometimes the existing system is simply to expensive. And sometimes the customer prefers to use a transparent open source solution due to the increasing problems in trust and survailance.

These are reasons, why customers decide to use privacyIDEA.

Today privacyIDEA provides several possibilities to perform such a smooth migration. E.g. the RADIUS token. But starting with privacyIDEA version 2.11 there will be an even simpler migration scenario. privacyIDEA 2.11 will be released on March, 18th. If you want to stay tuned, please subscribe to our newsletter.

Centrally defined RADIUS servers

With privacyIDEA 2.11 you get the possibility to centrally define RADIUS servers. This is similar to the possibility to define SMTP servers centrally, which was introduced in privacyIDEA 2.10.

Centrally defined RADIUS server "RSA SecurID"

Centrally defined RADIUS server “RSA SecurID”

These RADIUS server definitions now can be used within RADIUS tokens or policies!

Up to privacyIDEA 2.10 each user had to get his own RADIUS token. Such a RADIUS token points to the RADIUS server of the obsolete OTP system. As long as the user has no real OTP token within privacyIDEA, the user will be authenticated against the obsolete OTP system.

One policy for all users

Starting with version 2.11 you now can define a privacyIDEA policy based on this centrally defined RADIUS server.


The centrally defined RADIUS server “RSA SecurID” is used in the passthru-policy.

To do this, the existing passthru-policy was enhanced. The passthru policy fires, if a user has no token assigned within privacyIDEA. With the passthru-policy the authentication request is forwarded to the LDAP or AD or — new in version 2.11 — to a centrally defined RADIUS server.

This means, that you only need to define one single policy to start a smooth migration from your old OTP system to privacyIDEA. You can then enroll new tokens to the users within privacyIDEA step by step without a hurry or without doing a hard switch!


The scenario described in this post works flawlessly with all systems, that use a RADIUS server. Including systems like Kobil, RSA SecurID, SafeNet, Vasco (in alphabetical order).

Just ask us!