privacyIDEA 3.7 Released

Offline Login without IP restrictions and verified enrollment

We take great pleasure in releasing privacyIDEA 3.7 today. It has been a long way since version 3.6. We implemented a lot of fixes and smaller but interesting enhancements. However, the most interesting new features are probably the redesign of the offline-token, a token verification during enrollment and a new supported way for encrypting the sensive data in privacyIDEA with a hardware security module.

Hardware Security Modules

Hardware Security Modules (HSMs) are expensive. Especially if you need a network attached HSM that provides the necessary performance to encrypt the OTP seed for each authentication request. This is the way how privacyIDEA currently supported HSMs. It is secure – but it is slow (unless you have the right hardware) and costly.

In privacyIDEA 3.7 we provide a new security module with a different approach. The idea was born in discussing security and speed with an enterprise community member.

The new security module encryptkey.py still holds the encryption keys in a keyfile. But this keyfile again is encypted with an assymmetric key on an HSM. The keyfile is decrypted by the HSM on startup and then the encryption keys from the keyfile are stored in memory. This way the slow HSM operation will only occur when starting or restarting the web server process. This allows you to use much cheaper HSMs or even Smartcards to protect your key material.

Still – you should be familiar with smartcards or HSMs and know what you are doing, to avoid wrecking your senstive data.

Offline Token

privacyIDEA allows clients like the privacyIDEA Credential Provider to fetch offline information to allow a user to login with a specific HOTP token, even if the privacyIDEA server can not be reached. However, this was always bound to the IP address of the client machine.

We removed the IP binding and redesigned the process. This way it is now much easier and more robust to use an HOTP token for offline authentication at your Windows notebook.

Verify Enrollment

When enrolling a smartphone HOTP or TOTP token, the user needs to scan a QR code that was generated by privacyIDEA. Only after scanning this QR code with a authenticator smartphone app, the token is technically enrolled on the user side. Administrators reported that sometimes some users forgot to scan the QR code. Thus privacyIDEA deemed the token as enrolled, while nothing existed on the user’s smartphone.

With 3.7 the administrator can now force the user to enter a valid OTP value during the enrollment process. This way the user is required to scan the QR code to be able to provide the valid OTP value. Only then privacyIDEA deems the token as successfully enrolled.

Further Enhancements

There are a lot of further enhancements.

Policies can now also use web server environment variables as conditions.

In version 3.6 custom user attributes have been introduced. In 3.7 the administrator can now define event handlers to set or delete custom user attributes. This way, you could e.g. set an attribute to a user as soon as the user enrolls a certain token type. Then you could have authentication policies, that take this token type as a condition, only allowing those users to do certain things.

Possibilities are many. We do not know them all! Find yours!

You can find the complete changelog at Github.

If you are running privacyIDEA in mission critical environments, the company NetKnights which staffs the core developers, also provides services and support.

If you want to get involved with privacyIDEA you can also visit the community forum.