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

MFA – save time by switching to LinOTP today

Regarding MFA (Multi Factor Authentication) the well-known administrator mantra “Never change a running system” is not accurate anymore, given today’s speed of IT technology development. In fact, regular changes have become a necessity to keep up with competitive markets. This is particularly true, if the new technology is driven by steady development to avoid unnecessary issues in the foreseeable future.

LinOTP brings substantial benefits for MFA-backed environments. It has no token vendor lock-in, it is open source and API-first developed. It is easy to set up and to integrate in the first place – it takes only about half a day in a standard environment. And we make sure that transitions from existing MFA solutions to LinOTP are stable, fast and painless for architects as well as for the performing administrators and the users.

Continue reading MFA – save time by switching to LinOTP today

What does LinOTP’s API-first development mean for you?

LinOTP – the open source MFA solution – is developed with an API-first strategy in mind. For us at KeyIdentity this does not mean to dogmatically follow each and every REST guideline but to think about the easiest yet most flexible way of introducing new features to our API in terms of simplicity of integration before the feature is actually implemented, while remaining backwards compatibility. Therefore, our API for all of our customers is feature complete.
For an integration product such as LinOTP, an easy integration into the user’s environment is probably the most important key feature. While historically LinOTP’s most used integration practice is based on the RADIUS protocol together with the FreeRADIUS server shipped with the KeyIdentity LinOTP Smart Virtual Appliance (SVA), the HTTP based API recently gains more and more importance. Especially for web applications LinOTP’s HTTP based API allows for easier and deeper integrations.
LinOTP features a stateless HTTP based API for validation, returning responses in the simple-to-parse JSON format. Request parameters may be sent as URL encoded data in a POST request’s body. This article will show what the API-first strategy means for you and how to integrate LinOTP into your own web applications.
To demonstrate LinOTP’s API by example, we show you how to integrate the QR Token into your environment.

Continue reading What does LinOTP’s API-first development mean for you?