A lot of Interesting talks

The conference started on Friday. There were several professional training tracks and one track with talks. Although I am involved into PKI and certificates with Linux for a while, there is always something new, some other aspects, different angles to find. So now I got some insperiation where to look at by the “Linux PKI System Parts” talk. How new junior developers could be integrated into your team was elaborated on in “They don’t make ’em like they used to: Integrating Junior Developers into your team“.

On Saturday there were five parallel tracks and it was sometimes difficult to decide where to go.

I have not been looking actively into Samba for quite a while. I know Samba started with Heimdal kerberos. Back then this was a petty, since Heimdahl would not play nicely with 2FA. The MIT Kerberos allowed to pass the Authentication Request to a RADIUS server thus adding 2FA into the kinit process. I talked about this in 2013 in my Kerberos talk. Well, in Columbus I learned in the Samba talk, that you can run Samba > 4.7 also with MIT. Welcome 2FA!

Although I am not a DB admin I like to hear talks about databases – hoping to learn something. Most of the time I learn, that I am really no DB admin The talk about “Slow MySQL database session analysis” gave a lot of entertaining insights, how you could find slow database queries in large setups, so you would know, where optimization has to occur.

The talk “Personal Online Security, Privacy, and Password Management” was filled with distinct tips and and tricks what to do and which tools to use to improve your personal online security. A lot to digest!

The last talk of the day “Beyond Zero Trust” addressed the same topic but in a more general or maybe even philosophical approach. Some good thinking to conclude the day.

A lot of interesting talking

In between talks, during lunch at the hang out time in the evening the time was filled with a lot of personal talking. I have been to the Ohio Linuxfest the first time but felt very at home. Because everywhere people were interested in exchanging ideas and communicating. To me this was really distinctive compared to other conference I have been in the U.S., Germany, The Netherlands, Austria or Denmark. I have got dry lips during these days. This never happened on Linux conferences before (Might be the air condition

Great organization

I also liked the organization a lot. Speakers were greeted warmly and the night before the conference. The organizers always took care, that you would know where to go… even after the official hours (Thanks Warner!

The venue in the Hyatt Regency Hotel is a very good spot. Diner, lunch and the cocktail bar is outstanding. And this is maybe the point: You do not have to worry about life support issues. So there is a lot more time for talking.

A big thanks to the OLF staff! I can only recommend the Ohio Linuxfest to anyone!

Cash Money

In Germany certain disoriented politicians suggest the abolition of cash money. Arguing that cash money is used by criminals and terrorists. Abolishing cash money and only allowing electronical transactions, these transactions can be tracked and controlled. Crimes will be avoided and terrorism ended. Luckily there are other prominent statements to contradict this wired ideas.

But what does the abolition of cash money have to do with privacyIDEA?

Central Book Keeping

In the European Union we usually like to travel to other EU countries and pay with the same Euro, not having to change money or bother about any exchange rate. Usually this is very convenient.

Electronic transactions could be great and convenient, too. We do not need to care about bringing enough money, everything would be smooth and easy and one central book keeping instance would take care to transfer 100 credits from person A to person B. After the transfer is approved and completed, person B could hand person A the goods of interest.

But such a central book keeping instance would not only know, what money was spent by whom on what, but it could also restrict the amount of money person A is allowed to spent or person B is allowed to receive. Even worse this controlling instance could also disallow person A to spent money for certain goods or to buy from certain sellers at all. Thus people could be banned from buying cigarettes, certain medicine or unpleasant newspapers.

Again, what does this have to do with privacyIDEA?

No Central Book Keeping

We do not like to be controlled and we do not want you to be controlled either. Many two factor authentication services are running two factor authentication as — guess what — a service.  This in fact is such a central book keeping. Such a central service knows, who of your users authenticated where and when. And they could easily allow or disallow access based on other decisions than the right OTP value sent by your smartphone. You do not know and do not control the algorithms used.

This is why we offer privacyIDEA to run on premise. Under your control. With no central book keeping and with no fear, that conditions or laws might change tomorrow.

And this is why it makes me shiver, when I read about any idea for centrally controlled anything or the abolition of cash money.

Fight for your informational self-determination and stand up to keep your cash money!

…and use privacyIDEA!

To do openess and transparancy the honour I would like to elaborate on what has happened.

The empire strikes back

The subdirectory authmodules in the privacyIDEA github repository contained a module for ownCloud. In ownCloud speak an “app”. This tried to support ownCloud 8. It failed with ownCloud 9. This was due to the fact, that ownCloud <= 9 had no concept or API for attaching two factor authentication system. It even had no concept of passing authentication to another module. It only allowed to change the complete user module. I.e. authentication, user existance and authorization was not separated like you would be used to e.g. from PAM. And this is why providing a module for two factor authentication for ownCloud 8 and 9 was the biggest pain in the ass I ever experienced.

Now several simple users came around and popped up on the mailing list or at github. I call them simple, because they were not able to look behind the scenes, analyze problems, look at a line of code or even add a line of code. I experienced several occasions when such users complained about, that the old privacyIDEA “app” for 8 and 9 was not working as they expected.

Finally I got really sick of those users with this simple cosuming attitude. I got sick of claiming having a two factor solution for an application, which did not provide a decently designed and documented authentication interface. And this is why I happily deleted the old ownCloud plugin from the privacyIDEA github repository.

A new hope

Finally, ownCloud 9.1 was said to come with a new authentication API – which unfortunately again was designed without asking someone, who knows some things about two factors — like me! Big mistake! Nevertheless – I decided to give it a second chance. Thanks to the help of Christoph Wurst and Thomas Müller I was able to implement a new privacyIDEA ownCloud app for ownCloud 9.1.

As I am still very disappointed in any kind of “community” regarding the old ownCloud app (for privacyIDEA itself it is a complete other picture!!!), the privacyIDEA ownCloud App for 9.1 is not publically available, yet. I don’t want to hear any comsumers complaining about things they don’t understand or are not willing to dive into! But this is no problem. ownCloud users with a handful of accounts can happily use the TOTP app which probably willl run very well for them.

These words might sound hard to some of you. But you may appreciate that they are the real truth of mine!

The return of the Jedi

Power users or companies with many users have different requirements. They will also do two factor authentication a the firewall, at portals, terminal servers or the VPN. In this case it makes no sense to manage TOTP tokens within ownCloud. Because these tokens can not be used for the VPN. Other tokens would again have to be managed for the VPN somewhere else… And for the terminal servers…

Enterprise environments require to manage the tokens of the users at one central place. All users, for all applications. In this case privacyIDEA and the privacyIDEA ownCloud app make absolute sense. Customers should contact NetKnights GmbH, because this is the place where they will receive the privacyIDEA ownCloud App!

Kind regards

Cornelius

Everyone is invited to participate!

First I would like to tell about:

• Event Handler Framework
• PIN Handling
• random PIN during enrollment
• Text message (SMS) improvements

It is important to such an open source solution to get your feedback. So then the microphone will be open to everyone and we can discuss these features and future needs!

Please add your preferred time slot in this doodle survey.

We will use spreed meeting for this session – so all you need is either a browser (with flash – sorry) and a headset or a telephone. The browser will also allow you to view the shared screen.

Update

The conference will be on July 6th, 2016 at 10am CET.

EDIT: The time is 10am CEST. i.e. summertime. Enjoy the light!

You can register at the spreed conference. Please note: You need a flash enabled browser to view. You can either use your computers headset or you can use a normal land line or mobile phone to participate on an audio level.

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.

The classical concept of privacyIDEA was: You have a user database – a user store – and privacyIDEA just reads this user store. In classical scenarios such as the enterprise environment with the Active Directory user base this is a perfect concept, because users are already existing. Over time I had to learn that this covers only 95% of the real world. So in version 2.4 we added user management – or editable userIdResolvers.

Editable UserIdResolvers

The editable UserIdResolvers that allow the administrator to manage users from within the privacyIDEA Web UI is an important step for the upcoming version 2.10. The editable UserIdResolvers are only implemented for SQL databases at the moment, but the connector for the LDAP databases like Active Directory or OpenLDAP could be easily enhanced accordingly. But at the moment I don’t think, that someone would like to have his Active Directory modified by privacyIDEA.

Anyway – privacyIDEA 2.4 already contained an importand method in the SQL connector, the method to created a new user in the SQL database.

User Self Registration

Thinking of new use cases with privacyIDEA we came up with the idea to provide a privacyIDEA instance to the public. Or a company or a hotel could provide a privacyIDEA instance to guests, where guests could register a guest account. If it is possible to restrict the registration of a new account to let’s say email addresses, we could control which email addresses are allowed to created a new account. This way it could also be used within an huge organization without reading the users from an existing user source but by having the users (identified by the email address) register their own account.

I am sure, at the moment we do not see the whole potential of this new feature.

How does it work

The administrator needs to define a policy, that allows the registration of a user in the defined UserIdResolver. If this policy is defined, an additional link “Register” is displayed in the login page. Then users may enter account information and will receive a registration token (a kind of registration code) to be able to login with these two factors (The password they defined and the registration code, they received via email).

Notification

During the registration process the user receives an email with the registration token. Again – privacyIDEA needs to notify the user via an email. privacyIDEA already sends emails for the Email token type or the SMTP SMS Gateway token. Also, there is the PIN handler, which could send the OTP PIN, if a random token PIN was created during enrollment.

So you see, that there already were several places in privacyIDEA, where it could be necessary to define an Email connection. Sending the notification during the registration process would be the fourth occasion to send an email.

Now is the time to refactor the email notification code in privacyIDEA.

System wide SMTP server configuration

So the privacyIDEA database for privacyIDEA 2.10 will come with a new database table, where the administrator can define as many SMTP servers as he needs to.

In all occasions, when privacyIDEA needs to send an email, the configuration will only refer to the identifier of this SMTP configuration. Usually defining one SMTP configuration will be enough an this single SMTP server will be used for sending the email of an Email token and the registration emails and all other notification information to come.

But privacyIDEA would not be privacyIDEA if it did not let you the freedom and choice to define as many different SMTP connections as you will need.

More to come

With all these building blocks

• editable UserIdResolvers
• simple token implementations
• simple email notification

new ideas can be implemented easily and quickly. You can see this in the really short release cycles of privacyIDEA.

We are anxious to hear of your ideas, which I am certain of, can be easily implemented, too. Please join us on the Google group or drop your idea at privacyIDEA’s Github issues.

Happy new year and happy authenticating!

Two factor authentication or multi factor authentication is ment to raise the bar for attackers. They ought to sniff, brute-force or social-engineer your password and in addition steal or “borrow” your hardware token for a “test”.

Still, I wish to think that the Yubikey – being the product of originally a sole Swedish company – has no back doors. So as long as the TISA does not know of side channel attacks or you used a static password with the Yubikey, you might be fine as long as you get the same Yubikey back – undestroyed.

Nevertheless there are additional measures you can take to improve your security with privacyIDEA.

Disclaimer: This will only help, if you are using your hardware token to authenticate to remote systems. If you use your hardware token to unlock let’s say encrypted harddisk of your notebook, you are carrying, this will not help.

Set up privacyIDEA

When you manage your hardware token for remote access with privacyIDEA and you are crossing borders or you are in situations where you

1. think your hardware token could be stolen or otherwise compromised and
2. you do not need the token explicitly (since you are on the plane without internet access)

you might want to call your trusted privacyIDEA administrator (some call it help desk) and have your hardware token locked.

This way the hardware token can not be used to access restricted resources. If TISA is still insisting to get your Yubikey, you can say:

“If you take it, you can keep it”

(No of course you can take it back, but you may see it as compromised and you might need to reenroll it.)

If TISA takes the Yubikey there is not use for them, since the token is locked.

If TISA did not get your Yubikey and you crossed the border, customs or control successfully, you may call your trusted privacyIDEA admin again to reactivate the hardware token.

Conclusion

This might sound a bit complicated but also to simple. But special events like travelling to certain rogue regimes may require special measures.

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.