Do you know your network?

Can you tell how many devices are connected to your internal network at this moment? If so, how much do you know about these devices? Do you know which operating system is running on a specific IP address? Or when did this device first appear on the network? Which client has an important security patch missing?

This post is about identifying your IT assets (hardware, software, data), detecting unwanted devices and what Shadow IT means.

Continue reading Do you know your network?

Security in distributed Computing

Distributed computing is an awesome approach to distribute workload of huge tasks and easily outsource them, if needed. It makes computing tasks scalable and cheap, as cloud computing is involved. Computing time can be rent, which is mostly cheaper compared to buying the necessary hardware. However, outsourcing into foreign networks comes with the advantages and drawbacks of public infrastructure. Public networks cannot be trusted, therefore, traffic should be encrypted and connections should be authorized, which sounds easier than it is when using Python frameworks such as Dispy, Celery or Twisted.

Although implemented in the core of the frameworks I used, security is optional, sometimes flawed (e.g asynchronous cryptography in Dispy which uses the same private as well as public key on client as well as on server side, otherwise it will not work) and often with lack of good documentation.

The main priority of official tutorials is to make it work, period – so developers test the shown code and use it, without bothering about further security steps. Tutorials showing working code with all needed encryption and authorization steps are rare. Often framework developers are showing the needed parts separated, but not the complete setup. So developers have to spend a lot of time puzzling all needed steps together. Security should be implemented by default, which unfortunately is not often the case in official framework tutorials. It was therefore not easy to find documented literature to implement the frameworks in a secure way. Sometimes, the frameworks did not even offer complete secure solutions. Let us have look at a framework called Twisted in combination with a JSON-RPC server and how to secure it. There is still room for improvement, but I hope this blog-post will help developers hardening and securing their software a little bit more.

The example code can be found here.

Continue reading Security in distributed Computing

The concept of a penetration test

A penetration test – also known as a pentest – is a security and risk assessment of an application(s) and/or a system(s) performed by an IT security professional using manual, and sometimes, automated tests. While automated tests are meant to find low hanging fruits and maximize the coverage of the assessment, manual assessments are still required as many use cases cannot be tested or accurately identified with automated tests.

Continue reading The concept of a penetration test

FIDO U2F: what it is and how you can secure your web applications using LinOTP

This is the first part of a series of blog entries about FIDO U2F and how you can use FIDO U2F and LinOTP to secure your web applications.

Kicking off, we would like to introduce you to FIDO U2F and explain the idea behind it. Following blogs will be about the protocols and how you can use LinOTP to integrate FIDO U2F in your application.

What is FIDO U2F?

FIDO U2F is a technical specification defining a mechanism to reduce the reliance on passwords to authenticate users. It can be used to enrich a password-based authentication with a second factor or to replace the password-based login completely, depending on the use case.

FIDO U2F is developed by the FIDO Alliance (KeyIdentity is a member) and actively extended to new authentication models and markets. The driving idea behind FIDO U2F is to allow the user to bring their own token to their registration process and allow you to securely validate the identity of the user going forward and the user only having to use one token for all websites without compromising security.


Source: FIDO Alliance

USB, NFC and Bluetooth are now defined as transport protocols and a wide range of devices is available to make use of them. Your users can decide on the method and vendor they prefer, based on costs, design or availability. The FIDO U2F implementation on the side of the web application is the same for all tokens implementing the FIDO specifications.

FIDO U2F is based on public key cryptography. When the user registers at your site, a key pair specific to your site is generated in the FIDO U2F token and, depending on the device, is stored on the token. The public key is then registered in your LinOTP backend. When the user authenticates later on, a challenge is presented to the FIDO U2F token and proof of the possession of the private key is presented by signing the challenge. The FIDO protocols are designed to protect the user’s privacy. It is not possible to track a user across services even though the same token is used.

The handling of the device and the communication with the USB, NFS or Bluetooth transportation protocols is provided by the user’s browser and built-in or available as a plug-in. Currently only Google Chrome has built-in support, but support by Microsoft and plug-ins for Firefox are available.

FIDO U2F is still a pretty young standard, but adoption is picking up. After being developed mainly by Google and Yubico, the FIDO Alliance now has an impressive set of members and the range of specifications grew actively and in interesting areas over the last year.

This was just a quick introduction, in the following parts we will look at the registration and authentication process and how an implementation of FIDO U2F can look.