A Push Token is an advanced technology for an easy-to-use and secure multifactor authentication (MFA): When a user tries to access protected content or initiates a transaction, a push notification is sent to the users registered mobile device, for instance a smartphone. Continue reading The basics of multi-factor authentication: What is a push token and how can businesses benefit of it?
Multi-factor authentication (MFA) is based on the idea that a user possesses several unique pieces of evidence which cannot be provided or accessed by a third party. This can be either knowledge like a password, biometric features like a fingerprint or a physical object like a hardware token.
Modern MFA solutions like LinOTP and the KeyIdentity MFA platform support a wide range of tokens to accommodate different use cases, risk levels and cost considerations in B2B and B2C scenarios. Here is a short overview on most common token types: hardware and software tokens, SMS and biometrics as well as QR and push tokens.
Hardware tokens: independent of the device running the application
Hardware tokens are available in various designs ranging from portable USB authenticators to keychain devices to flexible display panels embedded in identification cards. They all have one advantage in common: Since hardware tokens come with their own display and battery, they can operate independently of the device running the application.
A special type of hardware token is the standardized FIDO U2F supervised by the open-authentication industry consortium FIDO Alliance. Based on the Universal Second Factor standard U2F, users can “bring their own token” (BYOT). This means that tokens already owned can be reused at a consistent level of security Continue reading The basics of multi-factor authentication: How to pick the right token
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.
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.
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.