Posts Tagged: security

Improved Device Detection

Whenever your user account is logged into from a new or unfamiliar device, MIDAS can automatically alert you by email. This additional security feature helps keep your account secure by alerting you to suspicious logins. An unfamiliar login notification includes details of the browser, operating system, IP address, and – with our optional Geolocation addon – location, of the device that’s just logged into your account.

Until now, MIDAS has been unable to distinguish between more recent operating system versions. For example, between Windows 10 and Windows 11, or between MacOS Ventura and Sonoma.

This is because MIDAS has relied on the “User Agent” (UA) string that’s presented by the browser that’s logging in.

Here’s an example of a browser’s “User Agent” string presented to a web server:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36

There’s a lot of information there, but essentially, from this string MIDAS can derive that it’s a Windows (64 bit) device, and the browser is Google Chrome 123.

Here’s another example:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:124.0) Gecko/20100101 Firefox/124.0

From this, MIDAS can derive that it’s a macOS device, and the browser is Firefox 124.

But wait… can’t MIDAS also determine the exact version of the operating system from these UA strings?

Mac OS X 10.15…. Catalina? …Big Sur? …Monterey? …Ventura?

Doesn’t “Mac OS X 10.15” imply macOS Catalina? ..and doesn’t “Windows NT 10.0” imply Windows 10?

Well, that used to be the case, but not any more!

Modern browsers now “clamp” the versions of more recent macOS/Windows operating systems reported by the User Agent string. For macOS operating systems, the User Agent string will report a maximum of macOS X 10.15. For Windows operating systems, a maximum of Windows 10 will be reported. Browsers no longer natively report the specific version of the operating system they’re running on.

This means that a Chrome browser running on either Windows 10 or Windows 11 will report “Windows NT 10.0”. Similarly, macOS Catalina (10.15), Big Sur (11), Monterey (12), Ventura (13), and Sonoma (14), will all report “Mac OS X 10.15”.

So Windows 10 and 11 are the same then?

In an effort to improve user privacy, browsers have decided to no longer reveal the specific operating system version a user is using when visiting a website, in order to make it harder for websites to “fingerprint” users.

“Fingerprinting” is a technique that some websites employ to uniquely identify and potentially track visitors.

So because of these changes to the way browsers report User Agent strings, it’s been difficult for MIDAS to provide a unfamiliar login notification containing details of exact operating system version that’s been used to login to an account.

But advancements in technology mean that we’ve now been able to make improvements to device detection for MIDAS v4.36.

Utilizing New “Client Hint” technology

Client hints are a set of HTTP request headers that provide useful information about the client such as device type and network conditions. This then allow servers to optimize what is served for those conditions.

Unlike the traditional “User Agent String”, client hints provide a more efficient and privacy preserving way of getting the desired information.

A web server can proactively request the client hint headers they are interested in. The browser can then include the requested headers in subsequent requests.

If the web server upon which a MIDAS system is running proactively requests either the “sec-ch-ua-platform-version” or “ua-platform-version” client hint header, MIDAS can receive details of the user’s operating system version.

Unfamiliar login notifications (if enabled) can then provide much more accurate information as to the operating system of the new device which has logged into your account.

Improved Device Detection in MIDAS v4.36
Improved Device Detection in MIDAS v4.36

Web Server Configuration

Because a web server has to proactively request these new client headers in order for browsers to respond to them, servers have to be configured accordingly.

All of our cloud-hosted nodes have been appropriately configured. Our client servers now proactively request the necessary Client Hint headers. This in turn means that all cloud hosted users can start to take advantage of these improvements to device detection and unfamiliar login notifications.

For self-hosted customers, a small configuration change to the web server when your MIDAS system is running from is required.

Details of the configuration change you’ll need to make can be found in our KB article, How to configure your server for Client Hints.


Proposal to drop TLS 1.2 support in early 2025

Proposal to deprecate Transport Layer Security TLS 1.2

Transport Layer Security – or “TLS”- is a cryptographic mechanism to facilitate secure connections and communications across the internet. For example, the https network connection between your device and secure websites or applications, like MIDAS.

Several incarnations of the Transport Layer Security protocol have been developed over the years, the most recent being 1.3:

ProtocolReleasedCurrent Status
TLS 1.01999Deprecated
TLS 1.12006Deprecated
TLS 1.22008In use since 2008
TLS 1.32018In use since 2018
TLS Protocol History

TLS 1.0 and 1.1 are now considered “legacy protocols” and “weak” by today’s cryptographic standards. That’s because they’re susceptible to several vulnerabilities. Modern web browsers automatically default to preferring more secure TLS 1.2 and 1.3 connections. In fact, they may even display a warning when connecting to a website that only supports the now obsolete TLS 1.0/1.1 protocols.

As security and cryptographic standards have evolved over the years, we have too! We’ve previously dropped support for TLS 1.0 connections to our network in 2017. We then subsequently dropped support for TLS 1.1 connections in 2020.

As part of our ongoing commitment to security, we’re now proposing to also deprecate support for TLS 1.2 connections to our client servers in early 2025. Going forward, we propose to only support TLS 1.3 (the latest Transport Layer Security protocol version) connections.

But wait.. isn’t TLS 2.0 still considered secure?

In the past few years, researchers have discovered cryptographic weakness in the ciphers and algorithms that TLS 1.2 uses.

While TLS 1.2 can still be used, it is no longer considered the most secure option. TLS 1.2 is only considered “safe” when weak ciphers and algorithms are removed.

On the other hand, TLS 1.3 supports the latest modern encryption with stronger encryption algorithms and more robust authentication mechanisms. TLS 1.3 is currently the most secure TLS version. At time of writing, TLS 1.3 currently has no known vulnerabilities, and also offers performance improvements over TLS 1.2.

What impact would disabling TLS 2.0 support have?

Most modern browsers and operating systems support TLS 1.3.

Therefore, the vast majority of users will be unaffected by our proposal to switch off support for TLS 1.2 in early 2025. However, if you’re using an older device or operating system, you may need to take action.

Here’s a list of browsers and devices that will be affected when TLS 1.2 connections are blocked:

  • Internet Explorer: All versions of Internet Explorer do not support TLS 1.3. This should not impact any of our users, as our MIDAS software has not been supported in IE since 2019.
  • Edge Legacy: Versions of Edge Legacy prior to April 2018 do not support TLS 1.3. Users would need to update to a newer version of Edge or a different browser.
  • Safari on macOS 10.12 Sierra or earlier: These older macOS versions do not support TLS 1.3 in Safari. Users would need to upgrade their macOS or use a different browser.
  • Very old versions of other browsers: Browsers that haven’t been updated in several years might not support TLS 1.3.
  • Older Android devices: Devices running Android 9 (and earlier versions) do not support TLS 1.3.
  • Older iOS devices: Devices running iOS 12 (and earlier versions) do not support TLS 1.3.

Web browsers and devices that do support TLS 1.3:

  • Microsoft Edge (current versions): Supported since April 2018 (Edge 79+)
  • Google Chrome: Supported since April 2018 (Chrome 70+)
  • Mozilla Firefox: Supported since October 2017 (Firefox 63+)
  • Apple Safari (on macOS 10.13 High Sierra or later): Supported since September 2018 (Safari 14+)
  • Opera: Supported since April 2018 (Opera 57+)
  • Android: Android 10 (or later)
  • iOS: iOS 13 (or later)

Important Information For Hosted API users:

If you’re a cloud-hosted MIDAS customer utilizing the optional MIDAS API you may need to take action before TLS 1.2 connections to our network are disabled in early 2025.

You’ll need to ensure that your applications and the underlying programming language you develop in can support (and are correctly configured for) TLS 1.2 connections.

For instance Java 7 (1.7) (and lower) and .NET 4.7 (and lower) languages don’t support TLS 1.1/1.2.

If your applications/programming languages do not support TLS 1.3 encryption, your MIDAS API calls will begin to fail in early 2025 once we disable TLS 1.2 support across our network.

Please refer to the vendor of your programming language if you’re unsure whether it supports TLS 1.3, or for assistance enabling such support in your development environment.

Remind me again.. when is this all happening?

Currently, we are proposing to drop support for TLS 1.2 connections to our network in early 2025.

We have not fixed a specific date in 2025 for this as yet (as we want to hear from you – see below).

However, anything can change over the course of a year. Should new vulnerabilities be discovered in TLS 1.2 during 2024, this may prompt us to bring our plans to deprecate 1.2 support forward.

We Want To Hear From You!

We are currently only proposing to deprecate TLS 1.2 connections to our network in early 2025.

However, we’re open to feedback from you our users in the meantime.

If you feel you have a particular usage case that would require continued reliance on TLS 1.2 support, please reach out to us to discuss.


Schedule regular Security Audits

You may not know, but MIDAS includes a built-in “Security Audit” tool.

This allows you to perform a quick and on-demand security analysis of your MIDAS system.

Perform a detailed Security Audit of your MIDAS room booking system
Perform a detailed Security Audit of your MIDAS room booking system

First introduced with the release of MIDAS v4.13 in 2016, the “Security Audit” tool tests a number of key metrics of your MIDAS booking system.

The audit checks your MySQL / MariaDB setup, MIDAS files, and recommended MIDAS security settings.

It provides a detailed report with appropriate advisories for hardening the security of your MIDAS system.

When the Security Audit was first introduced, it analyzed 15 metrics. Today, that number has increased to over 20.

For MIDAS v4.33, the audit now additionally also…

  • Indicates the number of recently failed login attempts to your MIDAS system.
  • Checks whether Geofenced logins have been enabled.

But the biggest improvement to Security Audits for MIDAS v4.33 is the ability to schedule regular automated security audits.

Until now, a Security Audit could only be manually initiated (via MIDAS Admin Options → Manage MIDAS → Security → Perform a Security Audit)

From MIDAS v4.33, you can now use Scheduled Tasks to automatically run a Security Audit and email you the results. Audits can be configured to run every 7, 14, 30, 60, or 90 days.

Schedule automated security audits of your MIDAS booking system
Schedule automated security audits of your MIDAS booking system

Geolocation and Geofencing

We’re excited to announce Geolocation and Geofencing support for our MIDAS room and resource scheduling software.

What is Geolocation?

Geolocation support in MIDAS room booking systems

Geolocation is the process of determining the geographic location of a user’s device. It is used in a variety of applications, such as mapping, navigation, and weather forecasting. A device’s location can be determined using a variety of methods, including GPS, cell tower triangulation, and IP address location.

IP address geolocation is a method of determining the position in the world of an IP address. This can be done by using a variety of methods, including:

  • Reverse DNS lookup: This method involves looking up the IP address in a DNS database to determine the name of the domain that is associated with the IP address. The domain name can then be used to determine the geographic location of the server that hosts the domain.
  • Geolocation databases: These databases contain information about the geographic location of IP addresses. This information is typically collected from a variety of sources, such as ISPs and network operators.

It is important to note that IP address geolocation is not always accurate. The accuracy of IP address geolocation depends on a variety of factors. These include the quality of the geolocation database and the method that is used to determine the geographic location of the IP address.

What is Geofencing?

Geofencing is an extension of geolocation. Once a device’s geographic location can be determined through geolocation, “Geofencing” can be used by a website or application to ensure that devices outside of an authorized area are denied access.

IP geofencing works by creating a virtual radius at a set distance around a fixed point on the globe. By comparing the latitude and longitude coordinates of a user’s device, with this fixed point, the distance between them can be calculated. This calculation will determine whether the user’s device falls within the set virtual radius.

Access form any device which falls outside of a set radius of the central fixed location can then be blocked.

Geolocation applications within MIDAS

Initially, there are two main areas within our booking software where geolocation information can be shown.

First, is the Recent Activity Log. This audit log in MIDAS records all user activity and actions taking place in your booking system. Each entry in the log is time-stamped, and shows the user account and IP address which performed the action.

From MIDAS v4.33, the optional Geolocation addon can be configured to allow location information to be shown for IP addresses in the Recent Activity Log. This location information includes the city, region, and country that the IP address resides in.

The second application for geolocation in MIDAS accompanies the unfamiliar login notifications feature.

The unfamiliar login notifications feature alerts users when their account is signed in to from a new device or location.

These notifications typically include details of the user’s device / browser and their IP address.

Geolocation support now means that you can optionally configure these notifications to now also include the city, region, and country that the login occurred from.

Geofencing applications within MIDAS

Building on the new geolocation support, Geofencing can be used to further enhance the security of your MIDAS system.

It can be used to restrict account logins to certain countries. For example, if your organization only has offices within the United States and the United Kingdom, your colleagues are typically likely to only need to login to MIDAS from within either the US or the UK. You can use geofencing to block any login attempts originating from countries other than the US or the UK.

Restrict MIDAS logins to certain countries
Restrict MIDAS logins to certain countries

Geofencing can additionally (or alternatively) also restrict account logins to within a certain distance from your location. For example, if you run a radio station in Manchester, UK, you could restrict logins to your MIDAS system to within say a 10 mile radius of Manchester.

Restrict MIDAS logins to within a radius of a set geographic location
Restrict MIDAS logins to within a radius of a set geographic location

How to enable Geolocation or Geofencing in MIDAS

The new Geolocation and Geofencing features are available for MIDAS v4.33 (or later) via our optional Geolocation addon.

Existing customers with active subscriptions can obtain this addon via mid.as/upgrade.

If you’re new to MIDAS, you can subscribe with the Geolocation addon via mid.as/pricing.

Geolocation data accuracy

The accuracy of IP geolocation data depends on a number of factors, including the quality and freshness of the geolocation database, the method that is used to determine the geographic location of the IP address, and the type of IP address.

The IP geolocation data we use in the Geolocation addon for MIDAS is never more than 30 days old.

In general, IP geolocation data is most accurate for large geographic areas, such as countries or states. It can become less accurate for smaller geographic areas, such as cities or neighborhoods.

That’s why if you use the distance based geofence features of the Geolocation addon, you should always set a larger liberal distance than necessary, rather than a very small strict distance from your location. The Geolocation addon does include an instant IP lookup test tool, so you can check IP distances before you apply them.

The Geolocation addon also includes “fallback” options for both country / distance geofence enforcement. For IP addresses where a country and/or latitude and longitude coordinates cannot be determined, you can configure MIDAS to either block or allow these connections.

It’s also worth noting that the accuracy of IP geolocation data can be affected by the use of proxy servers and VPNs. Proxy servers and VPNs can mask the true IP address of a device, making it difficult to determine the device’s geographic location.