This is a cheap way to establish two-factor authentication with something you know and something you have.

Several attack vectors for Two-Factor Authentication with SMS OTP

But lateley there are again some news about the vularability of OTP values sent via SMS. There are different attack vectors. In one scenario the attacker can reroute or “steal” the SIM card by doing social engineering at the telephone provider. In another scenario a malicious software is installed on the smartphone, that can sniff the OTP value.

Yes, privacyIDEA also supports sending OTP values via SMS and privacyIDEA is also vulnarable to these attacks – since it is the basic concept that lacks the necessary security.

Security is shades of grey — or white

But you might have heard that “there is no 100% security”. And that “security is a process”. And now I add to these idioms “Security is Shades of Grey”.

You gain security by using a password on your account to lock the desktop. But are you secure? You gain further security by adding a second factor during authentication. But is your data secure, now? You gain further security by encrypting the harddisk (a.k.a. your data) of your desktop. But is it secure?

Yes, it is good to use a password. You should not use none.

And yes, it is goot to use SMS OTP. It is better than to not use it. In certain cases it might be OK to use SMS OTP being aware of the possible risks.

But there are further steps or other possiblities to increase security.

Choice of Security Level

With privacyIDEA you have the choice, which security level you are going to use. And this may even depend on the application and the client.

You may use SMS OTP, Email OTP, Smartphone Apps like the Google Authenticator, hardware key fobs and seedable tokens like the Yubikey. Using privacyIDEA’s policy definitions, you can define which token type is allowed to be used for authentication at which application. This way you can accept the risk of using e.g. SMS OTP for low security applications and hardware devices like the yubikey for applications requiring higher confidentiality.

See the online documentation on policies for more information or come to the Google Group mailing list.

If you require any professional assistance you may contact the maintainer of privacyIDEA.

Today I will show you, how you can setup a scenario, where users can authenticate with Yubikey and/or Google Authenticator and you can define centrally, for which server the users need a Yubikey to authenticate and for which other server a Google Authenticator would be sufficient. Thus you can enforce security levels, meaning servers carrying more sensitive data can only be accessed with a hardware device like the Yubikey while others are ok to be accessed with a software token like the Google Authenticator.

Unique user, two tokens, many machines

You should already have read about enrolling yubikeys and how to use privacyIDEA for  two factor authentication to your server farm. So I assume, that you have a running installation.

You should have enrolled two tokens to the user root as depicted below:

The user root has a Google Authenticator (serial OATH…, OTP PIN “google”) and a Yubikey (serial UBOM…, OTP PIN “yubi”) token.

Both tokens can be used to authenticate from all configured clients. From localhost (172.16.200.41):

[root@centos6 ~]# echo "User-Name=root, Password=google977398" | radclient -sx localhost auth testing123
Sending Access-Request of id 167 to 127.0.0.1 port 1812
 User-Name = "root"
 Password = "google977398"
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=167, length=48
 Reply-Message = "privacyIDEA access granted"
Total approved auths: 1
 Total denied auths: 0
 Total lost auths: 0

[root@centos6 ~]# echo "User-Name=root, Password=yubi899739" | radclient -sx localhost auth testing123
Sending Access-Request of id 100 to 127.0.0.1 port 1812
 User-Name = "root"
 Password = "yubi899739"
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=100, length=48
 Reply-Message = "privacyIDEA access granted"
Total approved auths: 1
 Total denied auths: 0
 Total lost auths: 0

Or from a remote host (172.16.200.106):

cornelius@puckel ~ % echo "User-Name=root, Password=google308786" | radclient -sx 172.16.200.41 auth testing123
Sending Access-Request of id 11 to 172.16.200.41 port 1812
    User-Name = "root"
    Password = "google308786"
rad_recv: Access-Accept packet from host 172.16.200.41 port 1812, id=11, length=48
    Reply-Message = "privacyIDEA access granted"

       Total approved auths:  1
       Total denied auths:  0
       Total lost auths:  0

cornelius@puckel ~ % echo "User-Name=root, Password=yubi867011" | radclient -sx 172.16.200.41 auth testing123
Sending Access-Request of id 47 to 172.16.200.41 port 1812
    User-Name = "root"
    Password = "yubi867011"
rad_recv: Access-Accept packet from host 172.16.200.41 port 1812, id=47, length=48
    Reply-Message = "privacyIDEA access granted"

       Total approved auths:  1
       Total denied auths:  0
       Total lost auths:  0

The idea

The idea is to allow access on the machine 172.16.200.106 only with yubikeys. This is the machine that carries tons of sensitive data and we do not want users to authenticate with their Google Authenticator.

The host with the higher security level

To accomplish this privacyIDEA provides a special authorization policy that will only grant access, if the the authentication was performed with the correct token.

So lets configure a policy:

This policy tells the system, that if the client 172.16.200.106 issues an authentication request, it should only be approved, if the serial number of the authenticating token contains the string “UBOM”.

Note: As we are using RADIUS the client 172.16.200.106 issues a radius request to the RADIUS server 172.16.200.41 and the RADIUS server issues the request to the privacyIDEA server 172.16.200.41/127.0.01. Thus the request that arrives at the privacyIDEA server will always be issued by the RADIUS server. So we need to allow the RADIUS server to overwrite the client information – thus the RADIUS server will tell the privacyIDEA server, what the calling RADIUS client was.

We can set this in the system config.

We set the localhost and the eth0 IP of the RADIUS server in a comma seperated list: 127.0.0.1, 172.16.200.41.

The yubikey now can successfully authenticate at the sensitive host:

cornelius@puckel ~ % echo "User-Name=root, Password=yubi773998" | radclient -sx 172.16.200.41 auth testing123
Sending Access-Request of id 88 to 172.16.200.41 port 1812
 User-Name = "root"
 Password = "yubi773998"
rad_recv: Access-Accept packet from host 172.16.200.41 port 1812, id=88, length=48
 Reply-Message = "privacyIDEA access granted"
 Total approved auths: 1
 Total denied auths: 0
 Total lost auths: 0

while the Google Authenticator fails to do so:

cornelius@puckel ~ % echo "User-Name=root, Password=google850707" | radclient -sx 172.16.200.41 auth testing123
Sending Access-Request of id 24 to 172.16.200.41 port 1812
 User-Name = "root"
 Password = "google850707"
rad_recv: Access-Reject packet from host 172.16.200.41 port 1812, id=24, length=55
 Reply-Message = "privacyIDEA server denied access!"
 Total approved auths: 0
 Total denied auths: 1
 Total lost auths: 0

We can see this in the privacyIDEA audit log:

Google Authenticator is still good for default servers

But we can still use the Google Authenticator for the default server with lower security level:

[root@centos6 ~]# echo "User-Name=root, Password=google069728" | radclient -sx 172.16.200.41 auth testing123
Sending Access-Request of id 162 to 172.16.200.41 port 1812
    User-Name = "root"
    Password = "google069728"
rad_recv: Access-Accept packet from host 172.16.200.41 port 1812, id=162, length=48
    Reply-Message = "privacyIDEA access granted"

       Total approved auths:  1
         Total denied auths:  0
           Total lost auths:  0

We can check this in the audit log, again:

Conclusion

privacyIDEA can be used to enroll many different authenticators to your users and mange these devices centrally.

In a second step you can decide who authenticates where with which device without bothering to reenroll any device.

Thus you can enforce your security policies easily. Additionally the audit log keeps track of all events that do not comply to your security policy.