Under certain conditions a local, physical attacker can get access to passwords of previously logged in users from the WebUI.

Details

Preconditions

This problem occurs, if the following conditions apply:

1. A logged in user in the WebUI locks the WebUI or logs out and does not close the browser tab.
2. The attacker gets local access to the browser tab.

Affected versions

privacyIDEA < 2.21.4

Technical background

Advisory

• No third person should use the user’s computer/desktop
• The desktop should be locked, when the user leaves his desktop
• The browser tab should be closed, when the user has finished working in the UI.

Fix

This bug is fixed in the current version 2.21.4 of privacyIDEA.

Credits

• Affected version: up to privacyIDEA 2.11.2
• Propability: Medium
• Security Severity: High

Technical Background

The passOnNoUser policy is supposed to check if an authenticating user exists. If the user exists, normal authentication is performed. If the user does not exist in the user store authentication is immediately successful. This is useful in special scenarios, where the Application has several levels of authentication and privacyIDEA is just the second level. Users that do not exist in privacyIDEA will only authenticate with the first level and users, that have an account in privacyIDEA will need to authenticate with the second level.

The Bug: If the policy passOnNoUser is set, it is not checked, if the user exists. I.e. even users that do exist are successfully authenticated, without checking their OTP value or password.

Advisory

You need to disable a policy containing the passOnNoUser action or remove the passOnNoUser action from you policies immediately.

Fix

You should update to version 2.11.3 which is released today.

These SSSD offline functionalities is intended to increase performance to not contact the IdM server all the time. I wonder if the timeout can not only set to some seconds but also to go offline with the client.

The same blog post also talks about OTP multistep prompting. But when going offline you do not want to decrease security by just requiring the first factor. This is why privacyIDEA provides the hashed OTP values to the client to be able to authenitcate with two factors while offline.

Admitted, going online again is a bit tricky, since the concept of resynchronizating the offline client with the authentication backend also contains possible attack vectors.

I am curious how SSSD will face this problem.

Data Privacy Day

This day is foremost ment to sensitize companies and users to take care when handling with private data. Especially in social media. But you can not devide your social life from your work life. Many attacks may start in social networks and end up in the heart of the company where the original victim is employed.

This is why you should protect information, that can be used to initiate attacks. This can be personal information, that only you and your personal contacts know, addresses (Read this very interesting story), dates, usernames and of course any hints to passwords.

Data Privacy with privacyIDEA

The job of privacyIDEA is to keep the data in your organization safe. privacyIDEA does this by introducing a second factor for authentication. Credentials for any account gained from social engineering in social networks or phishing will not get the attacker in. If you are using a hardware second factor like a Yubikey or a Smartdisplayer OTP card the classic cracker is in a mess, since he would have to get out and perform a real life action like stealing the hardware possession.

When using privacyIDEA it respects your privacy. privacyIDEA is 100% Open Source and 100% Back door free. This way you can know every second what the system is doing and all your data and all your authentication decisions belong to you!

Also do Encryption

An additional measure to protect your data is encryption. To get help with authentication and encryption you may ask the company NetKnights.

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.

Users who might want to use privacyIDEA will wonder how crypto is handled. So this makes it easier for them to get a first impression without having to study the source code.

In fact this is also a good review for the project itself, too. At several places we still use hard coded SHA256. With the hashing of the OTP Pins and the signing of the Audit data.

But having this crypto paper at hand, we know, which places we need to touch in only a few years!

Under certain conditions a rogue user can login as an LDAP user to the privacyIDEA web UI or guess a static password part during authentication when the policy scope=authentication, otppin=userstore is used.

Details

Preconditions

This problem only occurs, when both conditions are met:

1. The LDAP resolver defines a wrong, not existing UID-Type.
2. The LDAP server is configured to allow anonymous binds.

Technical background

During the password verification process, the LDAP resolver tries to find the user with the given UID – defined by the UID type. It then uses the user objects DN to bind to the LDAP server.

If the UID type does not exist, the LDAP resolver will get an empty DN to bind to the LDAP server. Binding with an empty DN is equal to an anonymous bind. If your LDAP server accepts anonymous binds, the bind will be successfull and the password verification is regarded as successful.

Advisory

If you have an LDAP server, that allows anonymous binds, you should check your LDAP resolver. Please check, that the UID Type you specified, really exist.

Verify authenticating to the Web UI with an existing LDAP user, but with an invalid password.

Fix

This bug is fixed in this commit and will be release with version 2.6 shortly.