Tag Archive: security


We’re improving and simplifying the password reset process for MIDAS v4.19.

Due to the secure way passwords are stored by MIDAS, it’s not possible to “recover” a forgotten password, the only option is to request a password reset.

In the past, this process has been as follows:

  1. User clicks the “Forgot Your Password?” link on their MIDAS login screen
  2. The user then enters their email address and clicks “Reset My Password”
  3. MIDAS then emails the user with a reset confirmation link
  4. The user clicks the reset confirmation link
  5. MIDAS emails the user a new temporary password (which they’re required to change upon their next login)

We’re simplifying this process and so from v4.19 the process will instead be as follows:

  1. User clicks the “Forgot Your Password?” link on their MIDAS login screen
  2. The user then enters their email address and clicks “Reset My Password”
  3. MIDAS then emails the user with a temporary login link
  4. The user clicks the temporary login link and is prompted to enter a new password after which the user is logged in

This simplified password reset process removes the sending on two emails to users (a reset link followed by a temporary password), as just a single email will be sent. This also strengthens security as a temporary password is no longer sent via email.

This improved flow also addresses the issue of multiple password reset attempts and emails arriving out-of-order. For instance, take the following scenario:

  1. User initiates a password reset, receives an email with a reset link and clicks it
  2. Whilst the user is waiting for a new temporary password to be sent to them, the initiate a further password reset and click the reset link in that corresponding email
  3. The original temporary password email arrives, and the user attempts to use the temporary password. However, as they since initiated a second password reset request, the first temporary password is no longer valid

This caused confusion for a handful of users who’d attempted to reset their password several times within a matter of minutes couldn’t understand why the temporary password they received wasn’t being accepted.

The improved password reset flow for MIDAS v4.19 completely eliminates this. Even if a user initiates multiple password reset requests the links they receive via email will all permit the user to set a new password, until they have done so.

We’re sure these improvements will make it easier and stress free for users to reset their own passwords.

Along with these changes, administrators can also still specify how long password reset links are valid for (the default is 2 hours). This setting may be found via MIDAS Admin Options → Manage MIDAS → Security. For more information, please refer to the help documentation.

Of course, if a user isn’t able to reset their own password, any other administrative user who has been granted the “Can Manage Users & Permissions” user permission can reset a user password on their behalf.

Click here to continue reading about some of the other new & improved features coming in MIDAS v4.19!

MIDAS v4.19 is coming soon! To be notified when it becomes publicly available, please join our mailing list, or to be among the very first to try the v4.19 “Beta”, why not join the Beta Test? (We reward our Beta testers too!)

Let's EncryptDuring the course of May we’ve been migrating our domain’s security certificates from ones issued by GlobalSign to ones issued instead by Let’s Encrypt.

What Is A Security Certificate?

In essence, a security certificate is what allows you to connect to a website over a secure https connection (instead of traditional, insecure, http). A valid and strong security certificate is what ensures that the connection and traffic between your web browser and the website/service you’re using is encrypted.

What Is A Certificate Authority?

Put simply, a “Certificate Authority” (or CA for short) is an organization responsible for issuing and revoking security certificates for websites. Popular CA’s include Comodo, Symantec, GoDaddy, and GlobalSign to name but a few.

Which Domains Are Affected?

All mid.as domains and *.mid.as sub domains (including our cloud-hosted customer’s domains)

Why Is This Happening?

Our security certificates were due for renewal in June, and as part of our continuous commitment to provide visitors to our site and customers alike with the best possible experience, we took the opportunity to review who provides our security certificates. Let’s Encrypt provide HTTPS certificates to over 70 million domains, and switching to certificates issued by Let’s Encrypt allows us to simplify and automate the management of security certificates across our growing MIDAS network.

Will I Notice Anything Different?

In short, no!

In order to migrate our CA from GlobalSign to Let’s Encrypt, we needed to remove the previous GlobalSign (AlphaSSL) certificate from each *.mid.as domain and install a new Let’s Encrypt certificate in its place. We have being doing this in a phased transition for all *.mid.as domains during the course of May, and we’re pleased to report that this transition to Let’s Encrypt is now fully completed.

Here’s how the old and new certificate issuers now look for our *.mid.as domains:

CA Migration to Let's Encrypt

We’d also like to reassure hosted customers that no domains, URLs, or IP addresses have changed as a result of this CA migration.

If you experience any issues or have any concerns, please don’t hesitate to reach out to us and we’ll be happy to help!

A note for cloud-hosted API users

Whilst unlikely, depending upon your code and development platform/language, you may initially receive a certificate warning/error when mmaking API calls now that the security certificate for your dedicated *.mid.as subdomain has changed, which may prevent your code/app from working temporarily until you accept the new security certificate.

Also, in some rare cases, you may not be able to access the API if your platform/device is listed as incompatible in Let’s Encrypt’s certificate compatibility list.

Finally, please be aware that Let’s Encrypt issues auto-renewing certificates which are valid for fixed periods of 90 days.

Disabling TLS 1.0 in early 2017

TLS stands for “Transport Layer Security” and is a cryptographic mechanism used to facilitate secure connections and communications over the internet. Several incarnations of the TLS protocol have been developed over the years (1.0, 1.1, and 1.2), with 1.0 being the oldest and now approaching the ripe old age of 18!

TLS 1.0 is now considered a “legacy protocol” and “weak” by today’s cryptographic standards, as it is susceptible to several vulnerabilities. Modern web browsers automatically default to preferring TLS 1.2 or TLS 1.1 over legacy TLS 1.0 connections, however some older browsers do not support the more modern and secure TLS 1.1/1.2 protocols.

As part of our ongoing commitment to security, in early 2017 we intend to drop support for legacy TLS 1.0 connections to our client servers. The vast majority of users will be unaffected by this change, but if you’re using an older web browser/operating system, you may need to update.

The minimum browser requirements for MIDAS v4.14 (and later) have also been updated accordingly.

The following table of web browsers provides additional guidance as to any action you may need to take to ensure you can continue to access our site/your hosted MIDAS system in 2017:

Browser Version Comments
Microsoft Internet Explorer 11 OK (If you see the “Stronger security is required” error message, you may need to turn off the “Use TLS 1.0” setting via Internet Options → Advanced)
9-10 OK (When running Windows 7 or newer, however you’ll need to enable TLS 1.1 and TLS 1.2 in Internet Explorer by selecting the “Use TLS 1.1” and “Use TLS 1.2” boxes via Internet Options → Advanced)
Upgrade Required (Windows Vista, XP and earlier are incompatible and cannot be configured to support TLS 1.1 or TLS 1.2 – Please update your operating system)
8 (or lower) Please update to a more recent version of Internet Explorer
Microsoft Edge All Versions OK – No action required
Mozilla Firefox 27+ OK – No action required
23-26 OK (Use about:config to enable TLS 1.1 or TLS 1.2 by updating the security.tls.version.max config value to 2 for TLS 1.1 or 3 for TLS 1.2)
22 (or lower) Please update to a more recent version of Firefox
Google Chrome (Desktop) 38+ OK – No action required
22-37 OK – No action required (Provided you’re running Windows XP SP3, Vista, or newer, OS X 10.6 (Snow Leopard) or newer)
21 (or lower) Please update to a more recent version of Chrome
Google Chrome (Mobile) Android 5.0+ (Lollipop) OK – No action required
Android 4.4.x (KitKat) Device Dependent (Some Android 4.4.x devices may not support TLS 1.1 or higher. Please refer to your device manufacturer if unsure)
Android 4.3 (Jelly Bean) (or lower) Please update to a more recent version of Android
Apple Safari (Desktop) 7+ OK – No action required
6 (or lower) Please update to a more recent version of Safari
Apple Safari (iOS) iOS 5+ OK – No action required
iOS 4 (or lower) Please update to a more recent version of iOS

Important Information For Hosted API users:

If you’re a cloud-hosted MIDAS customer utilizing the optional MIDAS API, please ensure that your applications and the underlying programming language you develop in can support (and are correctly configured for) TLS 1.1/1.2 connections. For instance Java 6 (1.6) (and lower) and .NET 3.5 (and lower) languages don’t support TLS 1.1/1.2.
If your applications/programming languages do not support at least TLS 1.1, your MIDAS API calls will begin to fail in early 2017 once we disable TLS 1.0.
Please refer to the vendor of your programming language if you’re unsure whether it supports TLS 1.1/1.2, or for assistance enabling such support in your development environment.

UPDATE: 1st April 2017

In advance of dropping TLS 1.0 support across our entire network this year, we’ve initially dropped TLS 1.0 support on our dedicated Service Status site. If you’re not sure whether or not you’ll still be able to access your hosted MIDAS system once TLS 1.0 support is dropped in the near future, please visit https://midas.network. If you’re able to visit this site without issue, then you’ll still be able to access MIDAS going forward.

UPDATE: 1st July 2017

As of today, our servers no longer accept TLS 1.0 connections. If you’re unable to access our site/a hosted MIDAS system, please upgrade your web browser.

Security Enhancements in MIDAS v4.13

If you’ve been following our blog, you’ll already know that we’ve been busy putting the finishing touches to the next update to MIDAS. Whilst each new version of our world class room booking and resource scheduling software includes exciting new and improved features and functionality, we’re also proactively committed to providing a secure scheduling solution for your organization.

To that end, MIDAS v4.13 includes a number of security enhancements which we’ll outline below…

15-Point Security Audit

We’re including an on-demand security audit with v4.13, which administrators may access via MIDAS Admin Options → Manage MIDAS → Security. The audit, when run, will test a number of key metrics of your MIDAS system (including your MySQL setup, MIDAS files, and recommended MIDAS settings) and provide a detailed report with appropriate advisories for improving the security of your MIDAS system:
15-Point Security Audit

Password “Blacklist”

MIDAS v4.13 includes an list of passwords that are considered banned/blacklisted and therefore cannot be used by users when specifying a new password or changing an existing password. By default, the blacklist contains the Top 1000 most common passwords of 2016. Passwords such as “123456”, “password”, “qwerty”, etc.
For our self-hosted customers, the list of banned passwords is also editable (via the “bannedpw.dat” file within your MIDAS installation), allowing you to add/remove banned passwords.

Improved clean-up of Temporary Logs

MIDAS has included a “Keep temporary logs for x days” setting for many years. This setting has previously defined how long entries persist in the “Recent Activity” log (an audit log which records all user activity within MIDAS). For v4.13 we’ve extended the functionality of this setting to also cover the persistence of log files which MIDAS may create from time to time – for instance a log file is created if there are issues upgrading MIDAS from a previous version, or issues when importing data from another application, or when logging of API calls is enabled, etc. Whilst these log files would be retained until manually removed, the “Keep temporary logs for x days” setting will now ensure that these files are also removed after a specific period of time.

“Minimum” Minimum Password Length

MIDAS has also included a “Minimum password length” setting since its inception. This setting allowed administrators to set a minimum password length for all user passwords. Starting with v4.13 it will no longer be possible to set this value less than 5 characters.

Password Strength Indicator

Password Strength IndicatorOur password strength indicator has been a feature for administrators creating new user accounts since v4.07. For v4.13, we’ve also made this useful visual indicator available whenever an end-users changes their password. The visual indicator classifies the password as either “Very Weak”, “Weak”, “Fair”, “Good” or “Strong” as you type, with a corresponding color to match (i.e. Red = Very Week, Orange = Fair, Green = Strong). This classification is based upon a number of factors including the length of the password, the presence of upper and lower case letters as well as numbers and special characters, and whether the password has been blacklisted/banned.
We hope the addition of this visual indicator for end-users will help promote the use of strong passwords.

MIDAS v4.13 is expected to be made available to Beta Testers in the next few weeks, with a general release shortly after. We’re always looking for additional testers to help test and provide feedback/bug reports on pre-release versions of our software, like v4.13. Becoming a tester is free and no experience is required, and what’s more we’ll reward you for your participation! Find out more about becoming a MIDAS Beta Tester here.

If you would like to be notified when v4.13 is fully released, then why not join our Mailing List?

As part of our ongoing commitment to security, you may notice that “Security Enhancements” often appears in the changelog when we release new builds.

In this blog post we’ll shed some light on some of these “security enhancements” that were recently introduced in MIDAS v4.11 and v4.12.

IP Change Detection

Starting with MIDAS v4.12, If a logged in user’s IP address changes whilst they are logged in, then the system will automatically log the user account out, forcing the user to login again.

It’s rare that a user’s IP address would legitimately change mid-session, and so this additional security enhancement will not be noticed by the majority of our users.

What it does do however is strengthen user sessions against a “session hijack“. In general terms, a “session hijack” is when a malicious attacker takes over a user account by gaining access to the unique identifying token (or cookie) of an active user session.

With the new IP Change Detection implemented in MIDAS v4.12, should a user fall victim to a session hijack, the session would be immediately invalidated as the originating IP address would suddenly change from the valid user’s IP address, to the IP address of the attacker.

→ Tip: User’s IP addresses are also logged in each MIDAS system’s Recent Activity Log

Shorter Cookie Persistence

We’ve all come across website with “Remember Me” or “Keep Me Logged In” tick boxes on login screens, meaning that you don’t have to remember your username & password for the site each time you come to login. When you select this box, information is stored in a browser “cookie” and retrieved the next time you visit.

MIDAS has included a “Remember Me” tickbox on the login screen since v4.07 (September 2014). Previously, the cookie saved by your browser would persist until 1st January 2020 – some 4 years in the future!

This meant that if you were to login to MIDAS today, you could come back to the same browser in a few years time, and still login without needing to remember your credentials.

We felt this was a little too long for your browser to be retaining such data, and as such from MIDAS v4.12 the “Remember Me” option will only remember your details for a period of 90. If you do not login to MIDAS again within that period, you’ll have to manually enter your email address/password again.

Why is this better? Well, it ensures that “dormant” user accounts (i.e. accounts not logged into for over 90 days) don’t have lingering login details persisting in client-side cookies.

→ Tip: MIDAS Administrators can choose to disable the “Remember Me” option completely (via MIDAS Admin Options → Manage MIDAS → Security)

Improved Session Control

In MIDAS v4.11, we introduced a new security setting (MIDAS Admin Options → Manage MIDAS → Security → Session Control) to automatically log out any users that have remained logged in for more than a set number of hours.

This is different to existing “inactivity” logout setting, which causes users to be logged off after a period of no activity. The additional “Always force logout after…” setting will automatically log users off after a set period of time, regardless if they are “active” or not.

Why is this useful? Well, web browser extensions/addons exist which allow you to “reload” a web page (or part of a web page) on a recurring interval. This could potentially allow a user account to remain logged in indefinitely, even if the “Inactivity forces logout after…” setting was set.

For example, if “Inactivity forces logout after…” setting in MIDAS was set to “1 hour”, then usually 1 hour after a user’s last interaction with MIDAS, they will be automatically logged off. However, if an addon/extension were setup to “reload” part of MIDAS every 30 minutes, this would look like “user activity” to MIDAS, and so the account would never be automatically logged out.

To combat this, the new additional “Always force logout after…” setting was introduced for v4.11. If your business usually runs 9am-5pm, you could set this setting to 8 hours. This will mean that no user account can remained logged in for more than 8 hours in total. So if a user was to login at 9am and use a browser addon/extension to effectively remain logged in all day, they will still be automatically logged out of MIDAS at 5pm.

New Session Manager

MIDAS can be configured to allow concurrent logins to user accounts from multiple browsers/devices. When enabled, this would allow a user to be logged into MIDAS from their laptop, phone, and tablet all at the same time.

MIDAS v4.11 introduced a new “Session Manager” allowing users to see other devices they’re currently logged in from (including IP address and browser) and remotely log each of them out!

Improved Password Change Behavior

Given that MIDAS provides the ability (if enabled) to allow multiple concurrent logins to the same user account, In v4.11 we’ve enhanced security and made it so that if a user changes their MIDAS password, then all other devices they’re currently logged into from will be automatically logged out. Previously, changing a password from one device wouldn’t take affect on other devices a user was logged into until the next time they logged in.

Cryptographically-secure Random Number Generation

MIDAS stores passwords which are SHA512 hashed and randomly “salted”. The “randomness” of this “salt” has been improved starting with v4.11. Now, if the Perl module “Math::Random::Secure” is available on the server where a MIDAS system resides, then MIDAS will utilize this module to generate Cryptographically-secure random numbers.

You might also be interested in:
Tips For Keeping Your MIDAS Secure
[ Back to top ]