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.

You want to use two factor authentication for all your users? But you are always wondering how you should enroll an authentication device to every single of your users? Existing solutions do not provide convenient ways to equip thousands of users easily with a second factor?

Using automated processes with a REST API and an automating event handler privacyIDEA provides the necessary means to easily do this task.

At FOSDEM Cornelius will give a talk about how easy it can be using privayIDEA to enroll second factors to all your lots of users. Join FOSDEM in Brussels and February 4th and learn about those great features of privacyIDEA.

Secure Rollout of a smartphone app

The central new feature of privacyIDEA 2.21 is the possibility to enroll a smartphone token in a more secure way. privacyIDEA supported smartphone Apps like the Google Authenticator and FreeOTP right from the start. But you already might be aware of the problems with enrolling smartphone tokens.

This is why we added a 2-step enrollment in privacyIDEA 2.21.

2-Step enrollment in privacyIDEA 2.21

Using privacyIDEA you have now the possibility to enroll a smartphone token in a much securer way. The sensitive secret key is created from a part generated on the server side and a second part generated on the phone side. This way an attacker can no longer easily copy the smartphone token during the enrollment process. You can find a more technical specification of the two step enrollment in the online documentation.

The new privacyIDEA Authenticator App will support this new two step enrollment and is also backward compatible to the normal Google Authenticator enrollment URI. Ask the company NetKnights to be part of the beta testing phase of the privacyIDEA Authenticator App.

Easy administration

Many enhancements will make the daily life easier for the token administrator. The root user can now export an encrypted PSKC file. The data can then be imported to another privacyIDEA instance or to any other RFC6030 complient applicantion. The event handlers were also improved: The Notification handler now has more tags to be used in the body and the Federation handler can forward administrative requests.

Clean-up Audit log

Audit Log can be rotated in a more sophisticated way. The administrator can specify retention times for different log entries.

Better HSM support

Hardware Securtiy Modules can now be used to generate random numbers at many different places within privacyIDEA:

You can view a complete changelog at github.

Enterprise Edition

If you are running large mission critical setups, privacyIDEA is also available as Enterprise Edition with support and warranty/liability.

privacyIDEA going FOSDEM

The privacyIDEA project will be at FOSDEM 2018 on February 3rd and 4th. We have a stand in building H. Please join us there!

Self Registration and Password Reset

privacyIDEA comes with a new policy scope “register”. If this policy is set new users may create a new account. The creation of the account can be limited to certain realms or to certain email addresses. This way you can define, that only user with an email address from a certain domain are allowed to register.

The user will get an email with a registration token, that can be used to access the privacyIDEA Web UI.

User registration was also introduced in a previous blog post.

User registration is possible due to the concept of writeable userstores, which was introduced earlier. Another possibility that arises from the writeable userstores and which is introduced in version 2.10 is User Password Reset. In a user-policy you may define, if a user should be allowed to reset his userstore password.

Token Wizard

Enrolling tokens to the user is always quite a challenge. No project or installation works the same, has the same requirements and chooses the very same enrollment strategy. It always seems very tempting to let users enroll their tokens, hoping that this strategy will not generate high traffic and costs in the help desk.

With privacyIDEA 2.10 the token user selfenrollment was drastically simplified providing a token enrollment wizard. The token enrollment wizard can be enabled using a policy. The enrollment wizard will jump in, if the user has no token. When the user logs in to the WebUI he will be presented a two step enrollment without any distracting additional questions or choices.

The tokenwizard works for all kind of tokens. In this example it is a smartphone based Google Authenticator HOTP token.

Email

After all this user stuff another important feature is the configuration of the Email-capabilities in privacyIDEA. Emails are used at different locations like EMail Token, SMS Token, Registration process and Password Reset. Therefore you can defined SMTP Server configurations centrally and choose which SMTP configuration you want to use for the specified task.

ChangeLog

This is the complete changelog of version 2.10:

Version 2.10, 2016-02-11

Features

• User Registration: A user may register himself and thus create his new user account.
• Password Reset: Using a recovery token a user may issue a password reset without bothering the administrator or the help desk.
• Enrollment Wizard for easy user token enrollment
• SMTP Servers: Define several system wide SMTP settings and use these for
  • Email token,
  • SMTP SMS Provider,
  • registration process,
  • or password reset.

Enhancements

• Ease the Smartphone App (Google Authenticator) rollout. Hide otplen, hash, timestep in the UI if a policy is defined.
• Add import of Aladdin/SafeNet XML file.
• Add import of password encrypted PSKC files.
• Add import of key encrypted PSKC files.

Fixes

• Support LDAP passwords with special non-ascii characters.
• Support LDAP BIND with special non-ascii characters.
• Fix problem with encrypted encryption key.
• Fix upgrading DB Schema for postgresql+psycopg2.
• Fix UI displaying of saved SMS Provider.
• Do not start challenge response with a locked/disabled token.