Multi-factor authentication is ment to make user login more secure.
For this purpose, the user receives a possession factor in addition to his knowledge. The user presents the
possession factor when logging in to an application, and the application turns to an authentication server to
verify possession.
The verification or representation of the possession factor is usually based on cryptographic procedures
performed on the authentication server.
The application to which the user logs on must trust the response to the verification by the authentication server.
privacyIDEA
The privacyIDEA multi-factor system is open source and is operated by the IT departments of the companies or
organizations themselves – on premises.
I.e. there is a strong trust anchor. The company or organization runs the authentication server itself, the IT
department can verify and understand the functionality and has the authentication system under its own control.
Flexibility, Token Types and Encryption
privacyIDEA is a very flexible system.
It can map and automate any workflow.
Also the user or the helpdesk can assign many different types of second factors to the user. E.g.: Codes via
email, smartphone apps, Yubikeys as OTP tokens (one-time password tokens) or even WebAuthn tokens.
As mentioned at the beginning, the second factor is usually mapped via cryptographic methods. WebAuthn
tokens use elliptic cryptography with asymmetric key pairs. However, in the case of classic OTP tokens
(smartphone apps like Google Authenticator, inexpensive key fobs, the Yubikey in very compatible OTP mode)
these are symmetric cryptographic procedures. Here, the one-time password is calculated based on a
symmetric secret key (also commonly called "seed").
This seed is stored in the smartphone and in the privacyIDEA server.
It quickly becomes apparent that it is important to protect such symmetric keys in order to ensure security and
maintain trust.
In the privacyIDEA server, therefore, sensitive data (such as the seeds) has always been stored encrypted in the
database to protect it from access by unauthorized persons – even the database administrator.
This also strengthens the confidence of the users in the system: The individual IT employee cannot do
everything with the account or the second factor of the user!
Modularity and Flexibility
privacyIDEA takes a modular approach to the encryption of seeds and sensitive data, as it does in many places.
In the default setup, privacyIDEA uses an encryption key that is stored in the file system. At system startup, this
is read into RAM, and during operation this is used to decrypt the encrypted seeds and sensitive data read from
the database for use. This is a quick and inexpensive approach and protects the contents of the database. This
is because the encryption key in the file system is located in a physically different place.
Basic attack scenarios can thus already be mitigated.
In addition privacyIDEA offers with a second module (aeshsm) the alternative to keep the encryption key in a
hardware security module (HSM). These are usually network-based HSMs from manufacturers such as Thales
or Securosys. The seeds and sensitive data are read from the database and sent to the HSM where they are
decrypted so that privacyIDEA can now use the seeds to verify a one-time password.
This process happens every time privacyIDEA needs to access the seed of a token.
The encryption key in hardware, separate from the privacyIDEA server, makes this a very secure solution. An
attacker who would get hold of the database and the privacyIDEA server would not be able to use the key
material.
Even though this is the most desirable solution in terms of security, it has two disadvantages. The network-
based HSMs are very expensive and the process is significantly slower. However, since this decryption has to
be performed for every two-factor login, cost and performance can be the decisive aspect.
The Middle Ground
Luckily as of version 3.7, privacyIDEA offers a third way for companies and organizations to encrypt sensitive
seeds with a new module (encryptkey).
Here, a physical hardware security module is used to decrypt the encryption key once at system startup and
hold it in RAM.
In contrast to the original scenario, the HSM is not used for all requests, but only once at startup. It would be
possible for an attacker to attack the RAM in order to obtain the encryption key. However, the simpler and more
frequent attacks by backing up the database, pulling off the file system or the virtual machine are already
secured with this.
A big advantage here, however, is that this method has the same speed as the standard setup when the
encryption key is in the file system.
Since the HSM is only used at the beginning, less powerful/simpler and much cheaper HSMs can also be
selected here.
For example, this setup can easily be operated with one or more YubiHSMs, so that companies can already get
by with a fraction of the costs for network attached HSMs.
The Freedom of Choice
For us as the developer of the open source software "privacyIDEA" it is important that organizations and
companies have control and freedom of choice.
We are happy to provide the possibility that everyone can implement the right solution for their purposes in
regards to encryption and trust.
If you want to learn more about privacyIDEA and hardware security modules, contact us!
