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!

Today privacyIDEA version 2.6 was released. This release eases the way of authentication by providing a new token TiQR. The TiQR token is based on the OCRA protocol, which is a challenge response protocol, that can be used to authenticate or to sign transaction data.

The TiQR token is a smartphone app. Authentication is as easy as scanning a QR code.

Furthermore you can now login to the privacyIDEA Web UI using challenge response. Each token, that supports challenge response, can be used to authenticate at the Web UI. This can be simple HOTP or TOTP tokens but also tokens like SMS or Email. Of course authenticating with the new TiQR token is also possible. See this screencast to get an idea of the smooth authentication.

Another interesting new feature is the 4-eyes token. This token is a meta token, that bundles two existing hardware token to one. This way you can require a two man rule for certain sensitive accounts. It was already introduced in this blog post.

This is the complete changelog:

Features

• Add OCRA base TiQR token to authenticate by scanning a QR code.
• Add Challenge Response authentication to Web UI.
• Add 4-Eyes token, to enable two man policy. Two tokens of two users are needed to authenticate.
• “Revoke Token” lets you perform special action on token types. Tokens can be revoke, meaning they are blocked an can not be unblocked anymore.

Enhancements

• Add HA information in the documentation.
• Add OpenVPN documentation.
• Add challenge response policy, to define if e.g. HOTP or TOTP are allowed to be used in challenge response mode.
• Add hotkeys for easier use of Web Ui.
• Remove wrong system wide PassOnNoUser and PassOnNoToken.
• Set default language to “en” in Web UI.

Fixes

• Fix LDAP bug #179, which allows authentication with wrong password under certain conditions.
• Small fixes in coverage tests.
• Fix username in web UI during enrollment.
• Fix link to privacyIDEA logo in Web UI.
• Fixed bug, that user was not able to resync his own tokens.

I am really puzzled and scared by many modern “security” consultants who claim the smartphone to be the next security device or even my identification object. Knowing that

• the smartphone has more cores than most desktop computers,
• is connected faster to the internet (thanks to LTE) than most land line bound computers
• and most older smartphones get no software updates fixing security issues,

this is a really scary scenario.

And the scariest thing of all is, that most users are not aware of this and are installing third party applications (belittling it as “App”) by a blink of an eye or the touch of a finger tip. Waving through all rights and access grants such an “App” wants to get.

Knowing this I am getting sick reading sentences like that on a daily basis:

We can achieve the same level of security as from a physical token using a simple app and a public algorithm to generate Time-based One-Time Passwords (TOTP), for example.

http://www.businesscomputingworld.co.uk/the-end-of-the-password-as-we-know-it/

This in fact is not true. A hardware token has NOT far as many attack vectors like a smartphone, from which you can steal the secret key, that is used to calculate the OTP values. TOTP (RFC6238) is based on HOTP (RFC4226) which relies on a secret shared key. This secret key is used to generate the OTP value. If the secret key is stolen from the smartphone either by

• physical access to the smartphone or
• by remote access via a trojan

the key is also known to the attacker.

And now comes the nasty part with TOTP: As TOTP only relies on the secret key and the time (which is known to everyone), an attacker can impersonate the user WITHOUT him NOTICING it. The OTP value an attacker generates will be a valid OTP value. The OTP value, the user generates a few minutes later, will also be a valid OTP value. The user will only experience a small “hickup” if he would try to authenticate within 29 seconds after the attacker did. Would the user care? Or would he just try a second time?

Don’t get me wrong. The smartphone with a Google Authenticator or FreeOTP is a great device to increase security in an easy and CHEAP! way. But it has those problems a hardware token does not.

A preseeded hardware token of course has the problem, that the secret key was installed at the vendors site and I do not ask you to trust the vendor.

But there are also hardware tokens that you can initialize yourself. Then you are the only one who knows the secret key and the secret key can not get extracted from the hardware remotely.

So it is important to know what you are doing and decide which level of security you want to achieve. But it is a sham telling that a smartphone will get you the same level of security as a hardware token does!

Luckily you can choose what level of security you want to achieve, when using privacyIDEA.