We’ve redesigned and improved the sign-in experience for MIDAS v4.39.

In previous versions, two options were offered on the sign-in screen..

Remember Me

Previously, the login screen included a “Remember Me” tick box. If this was selected when a user logged in, MIDAS would store their credentials in a cookie. The next time they accessed the login screen in the same browser, MIDAS would read this cookie and automatically populate the various fields on the login screen.

Auto-Login

An optional “Auto-Login” box was also present on the login screen whenever the “Remember Me” box was selected.

If “Auto-Login” was also selected, then the next time the user accessed the login screen, MIDAS would not only read the ‘remember me’ cookie and automatically populate the fields on the login screen, but also automatically click the “Login” button.

Drawbacks

There were a number of drawbacks to this approach. The primary drawback being that the “Remember Me” option stored a user’s credentials in a cookie. Whilst this data was encoded and obfuscated, it is no longer best practice to store such data in this manner.

The “Remember Me” option is also now somewhat outdated redundant. It was first introduced some 16 years ago – way back with MIDAS v2 in September 2009. Back then, password managers weren’t really a thing, and web browsers themselves didn’t provide a means to remember logins to websites.

Nowadays, all modern browsers off users the ability to remember credentials to websites and webapps. In addition, third party password managers are now also common place.

So it was time to give the “Remember Me” function a complete overhall.

In doing so, we also wanted to address a frustration which a number of our customers have reported over the years. If, when using MIDAS, they accidentally hit their browser’s reload/refresh button, MIDAS jumps them back to a login screen. (That is, unless they had selected both the “Remember Me” and the “Auto-Login” options when they initially logged in).

To combat this frustration, and to simplify the number of options on the MIDAS login screen, starting with v4.39 users will see a single “Stay signed in” option on their sign in screen.

The previous “Remember Me” and “Auto-login” options have been removed.

Staying signed in

Selecting this new “Stay signed in” option when signing in will keep the user signed-in to MIDAS on that browser until they sign out (or until their session times out, based upon the security settings setup by an administrator in your booking system.

Here’s how the new sign-in screen looks:

Like the previous “Remember Me” option, the new “Stay signed in” option also stores data in a cookie. However, unlike the former, the new “Stay Signed In” option only stores a randomly generated and unique session ID. No credentials themselves are stored in a cookie.

Refreshing and Reloading

Regardless of whether the new “Stay signed in” option is selected on a user’s sign-in screen, once the user has signed in, hitting refresh or reload in their browser will no longer jump the user back to a login screen – they will remain signed in!

With the “Stay signed in” option selected (and assuming the user isn’t accessing via a private/incognito browser window), the user can completely close their browser, and the next time they open it and access your MIDAS URL, they will still be signed in.

Security Considerations

Naturally, if the browser/device you use is shared by multiple people, then you should not select the “Stay signed in” option when signing in to MIDAS.

An administrative setting also exists to prevent the “Stay signed in” option from being shown to users.

An administrator may also still wish to force user’s sessions to expire if there is an extended period of no activity. To accommodate this, new settings have been added to the Session Control section of the security screen. This screen may be accessed via MIDAS Admin Options → Manage MIDAS → Security.

The post New “Stay Signed In” feature appeared first on MIDAS - Room Booking System | Blog.

Two-Factor Authentication (sometimes referred to as 2FA) is a more secure method of logging into websites or online services.

Traditionally, when you “log in” to a website or online service, you enter your username (typically your email address) and password. Then you click a button, and if the details you enter are valid, you’re logged in.

Unfortunately, many people reuse the same credentials (username / password combination) again and again for multiple websites and online services. The danger of this is that if one of those services gets “hacked” or suffers a data breach where user credentials are exposed, an attacker could potentially then access all other websites and online services that that person uses.

Two-factor authentication combats this. It does so by employing a secondary means of authentication in addition to the traditional username / password combination in order to authenticate a user’s access.

This means that even if a user’s password has been compromised, an attacker couldn’t then this to gain access to someone’s account.

Two Factor Authentication in MIDAS

Since 2015, all MIDAS room booking systems have included optional two-factor authentication. If enabled, this adds an additional layer of account security to our software.

With Two-Factor Authentication enabled, each time a user logins in, a code is sent to their email inbox. The user must then enter this code into MIDAS in order to complete their log in.

But starting with MIDAS v4.38, we’re improving 2FA options and support in our software!

MIDAS v4.38 (and later) now support authenticator apps – including Google Authenticator and Microsoft Authenticator – as an alternative 2FA login option to email.

Per User Two Factor Authentication Settings

Previously, the 2FA option in MIDAS was a ‘global’ setting. This meant that it could be enabled or disabled for all user accounts at once. It was not possible to have ‘per account’ 2FA settings.

We’ve made this more flexible for MIDAS v4.38!

Now, administrators can set whether 2FA is enabled for each individual user account. The 2FA option for each account can also be set.

Available 2FA options are now:

• Authenticator App
• Email

Enabling 2FA Authenticator App Globally in MIDAS

To globally turn on 2FA for all users, administrators can go to MIDAS Admin Options > Manage MIDAS > Security. In the “Two Factor Authentication (2FA)” section, tick the “Enable Two-Factor Authentication For All Users?” box, and then select the “Authenticator App” option:

Click “Save Changes” and 2FA via Authenticator Apps will be enabled for all user accounts.

Enabling 2FA Authenticator App For Individual User Accounts

2FA options are also available on a per-user account basis. Administrators can enable, disable, or change the 2FA method on a user account by going to MIDAS Admin Options > Manage Users & Permissions.

Select the user account you wish to enable 2FA for, and choose “Authenticator App” from the “2FA Login” setting:

Then click “Save Changes”.

How 2FA via an Authenticator App Works

When 2FA authentication via authenticator apps has been enabled on a user’s account, the next time they login, they’ll be presented with a QR Code to scan with their authenticator app:

If they’re unable to scan the QR Code a ‘secret key’ is also provided which can be manually entered into authenticator apps.

The user’s authenticator app will then generate a 6 digit code which they can enter into MIDAS to complete their login.

The QR Code / Secret Key needs only to be scanned/entered into the user’s authenticator app once upon first use. For subsequent logins, the user will simply need to enter the 6 digit code generated by their authenticator app:

Supported Authenticator Apps

Popular FREE authenticator apps supported by MIDAS include:

• Google Authenticator (available for Android and iOS)
• Microsoft Authenticator (available for Android and iOS)
• Apple Passwords App (included starting with iOS 18 and macOS Sequoia)
• 2FAGuard (available for Windows)
• 2fast (available for Windows)
• Authme (available for Linux, macOS, and Windows)
• KeePassXC (available for MacOS, Windows, and Linux)
• Password Manager SafeInCloud (available for Android, iOS, macOS, and Windows)
• Protecc (available for Windows)
• SafeNet MobilePASS+ (available for Android, iOS, and Windows)

However, any OTP authenticator app which generates Timed One-Time Passwords (TOTP) derived from a shared secret value and the current time should be compatible. TOTP codes are typically six digits long and change every 30 seconds.

Resetting 2FA

If a user looses their authenticator app, an administrative user in a MIDAS system can change the user’s 2FA method, or reset their authenticator token. By resetting a user’s authenticator token, the next time the user logs in, they’ll be presented with a brand new QR Code/Secret Key to enter into their authenticator app.

Availability

2FA login authentication has been available since MIDAS v4.10 (2015). However, this implementation is limited to authentication codes sent to users via email. 2FA could also only be enabled globally (for all user accounts)

2FA login authentication via either email or authenticator apps is available in MIDAS v4.38 or later. These options can be enabled globally, or an a per user account basis.

The post Authenticator App Support appeared first on MIDAS - Room Booking System | Blog.

In this post, we’ll outline what’s changing and explain the reasons behind the decision to remove these options.

“SSL Access” setting has been removed

In the early days of the World Wide Web, you connected to websites over “http”.

“http” connections were not secure and could be intercepted. So along came “https”, which allowed visitors to connect to websites over encrypted Secure Socket Layer – or SSL – connections.

However, adoption of “https” was initially slow by the majority of the World Wide Web. Primarily, this was due to SSL certificates being very expensive. Large financial institutions were naturally quick to jump on https. However, the price of SSL certificates put securing websites with https out of reach of the average webmaster. Especially when the cost to renew them every 1-2 years was factored in.

Now, as you may know, we’ve been developing our web based MIDAS room booking software for nearly 20 years now! When we first began to offer a “cloud hosted” booking system to customers (way back in 2007), SSL/https use around the web was not wide spread, and was expensive to implement.

Initially in 2007, we offered our cloud-hosted customers the option of being able to access their hosted MIDAS system over secure https. This was available via an optional (paid) addon for their scheduling system.

By June 2011, we’d recognized the importance and benefit of secure SSL connections for all our customers to their MIDAS systems. We therefore introduced better support for secure SSL connections with MIDAS v3.13.

As part of this, we added a new “SSL Access” setting to v3.13. This allowed administrators to control whether insecure http and/or secure https connections would be permitted to their MIDAS system.

In August 2012, we then took the further decision to include an SSL Certificate to enable secure connections for all our existing and future cloud hosted customers. At the same time, we enforced https connections to all hosted MIDAS system.

Consequently, the “SSL Access” option first introduced in MIDAS v3.13 became redundant for our cloud-hosted customers. Since 2015 and MIDAS v4.09, this option has no longer been available in cloud-hosted editions of our booking system.

In the following years, gradually the cost of SSL certificates reduced. Then in 2016, along came a game-changing service called “Let’s Encrypt“. Let’s Encrypt offered FREE SSL certificates for all. This finally allowed every webmaster the ability to “secure” visitor connections to their websites at zero cost.

In May 2018 we migrated all our cloud-hosted customer’s SSL certificates from expensive GlobalSign certificates to ones issued for free by Let’s Encrypt instead.

Now, in 2024, SSL/https certificates are the norm – in fact, all modern web browsers now alert you if you attempt to visit an insecure website via http.

So whilst we removed the “SSL Access” settings in cloud-hosted MIDAS systems back in 2015, we’re now also removing these settings for self-hosted customers starting with MIDAS v4.37.

“Allowed IP Range” setting has been removed (self hosted editions only)

The “Allowed IP Range” setting is one of the earliest security settings we provided in our room booking system. In fact, it was first introduced in v1.35 back in August 2007.

The setting allows an administrator to restrict access to their MIDAS system to an IP address or range.

This can be useful if a MIDAS system is hosted on a public-facing web server, which potentially could be accessed by anyone worldwide. The “Allowed IP Range” setting can be used to restrict access to users in your own country, organization, or to just you!

However, one of the limitations of this setting is that it only supports ipv4 address, and not ipv6 addresses.

Also, in the years since this setting was first introduced, other security and firewall products are available which provide greater control over access to websites, apps, and servers.

Therefore, starting with MIDAS v4.37, we have removed the “Allowed IP Range” setting in self-hosted editions.

If you’re a self-hosted customer and wish to restrict access to your MIDAS system by IP address you should consider other options to achieve this.

For instance, on Apache servers, you can easily allow/deny access by ip address/range in your httpd.conf or .htaccess files. For more information, please see Apache’s guidance on access control.

“Do Not Track (dnt)” has been superseded by “Global Privacy Control”

“Do Not Track” – or ‘dnt’ for short – was an official HTTP header first proposed in 2009. It was intended to allow user to opt-out of tracking by websites.

By 2011, all major web browsers had implemented support for the proposed “Do Not Track” features.

In 2017, with the release of MIDAS v4.16, we included an “Honor user’s Do Not Track preference” setting.

If enabled (and if an end-user had also enabled the “Do Not Track” feature in their browser), MIDAS would not log the user’s IP address in the Recent Activity Log.

However, globally, recognition and support of the “Do Not Track” HTTP header by websites was poor. So much so that in January 2019, the “Do No Track” HTTP header was officially deprecated. A month later, Apple removed DNT support from their Safari browser.

Whilst some other browsers still continue to offer a “Do Not Track” setting, it has since been supersede by a new “Global Privacy Control” – or GPC – header.

At time of writing, Global Privacy Control is still classed as an “experimental” and “non standard” technology, and it’s behaviour may change in the future.

But for MIDAS v4.37, we’ll support both DNT and GPC features. The “Honor user’s Do Not Track preference” setting will be renamed to “Honor user’s privacy preferences” to reflect this.

It’s likely that in a future update we’ll fully drop support the deprecated “DNT” header. At time of writing though, as some browsers still support it, we’ll continue to support it too.

The post Deprecating some outdated settings appeared first on MIDAS - Room Booking System | Blog.

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.

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.

The post Improved Device Detection appeared first on MIDAS - Room Booking System | Blog.

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:

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 1.2 still considered secure?

In the past few years, researchers have discovered cryptographic weakness in some of 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.

When will TLS 1.2 be deprecated?

At time of writing, there has been no date announced as to when TLS 1.2 will be officially deprecated.

However, one day TLS 1.2 will become obsolete, just as its predecessors TLS 1.1 and TLS 1.0 have become.

TLS 1.3 is currently the most secure TLS version. We’re keen to aid its adoption and to ensure the most secure connections to our network and servers. This is why we’re proposing to stop supporting older TLS 1.2 connections in 2025.

What impact would disabling TLS 1.2 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: No 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 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 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 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.

The post Proposal to drop TLS 1.2 support in 2025 appeared first on MIDAS - Room Booking System | Blog.

This allows you to perform a quick and on-demand security analysis of your MIDAS 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.

The post How to Schedule regular Security Audits appeared first on MIDAS - Room Booking System | Blog.

What is Geolocation?

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.

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.

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.

The post Geolocation and Geofencing appeared first on MIDAS - Room Booking System | Blog.

In October 2020, it came to light that Public Health England (PHE) had “lost” nearly 16,000 COVID-19 Test Results.

The issue arose by the way the health agency compiled results from the various commercial firms paid by the UK government to analyze Coronavirus swab tests of the public, to discover who has the virus.

These private firms provided their data in the form of CSV (Comma Separated Values) files – essentially text files.

PHE had set up an automatic process to pull this data together into Microsoft Excel templates so that it could then be uploaded to a central system. From there it could be made available to the NHS Test and Trace team, as well as other government agencies.

The problem was that PHE’s own developers picked an old Excel file format to do this – XLS.

Excel’s XLS file format dates back to 1987, and was superseded by XLSX in 2007.

In the original XLS format, each file could only handle around 65,000 rows of data. The more modern XLSX format can handle well over a million rows!

As a consequence of using the outdated XLS format, nearly 16,000 positive Covid-19 test results were “truncated” and not correctly recorded.

Whilst the 15,841 individuals who tested positive were themselves notified of their result and told to self-isolate, the people they’d been in recent contact with weren’t.

It’s estimated that in the region of 40,000+ contacts were not traced by the NHS’s Test & Trace team simply as a result of PHE using obsolete software.

Why were Public Health England using 13+ year old software?

There are many reasons why organizations may continue to use outdated software in their operations, including:

Cost

One of the most common reasons for not updating software is the cost. For large organizations which may have thousands of workstations and devices, the cost to keep software up-to-date can be prohibitive. Good businesses will plan and budget for these large expenditures and take advantage of bulk discounts and site-wide software licenses.

Compatibility

Most businesses use multiple software products from different vendors. Often compatibility between these products is required. Not all software titles used by a business are regularly updated by their developers. Some may not have been updated for several years! Often a factor preventing organizations from updating software to more recent versions is when there’s a risk that doing so would break compatibility with other software they use that’s not been updated for years.

This is actually one of the reasons that Internet Explorer 6 and then 8 stayed around for so long. These were aging browsers, but many 3rd party web applications which hadn’t been updated in years wouldn’t run in more modern browsers. This effectively forced Microsoft to continue providing support for their fledgling browser for years.

Human Resources

Some organizations lack the in-house personnel or expertise to roll out company-wide software updates. Again, cost can be a key factor here.

Other organizations “outsource” their IT, and rely on a 3rd party provider to keep all their software up-to-date. Most IT providers will routinely do this. However, some take the attitude that if the customer doesn’t know – or isn’t asking – about updating software on their systems, then why do it?

Business Interruption

Some organizations are concerned that a large scale roll-out of a software update company wide could cause or “down-time” or other unintended issues. This may intern affect staffs ability to do their work.

A “phased” upgrade approach – rather than updating every device at the same time – may be more sensible. However, this approach could result in compatibility issues if some staff are using a newer version of certain software, at the same time that other staff are still using the older version.

We suspect in the PHE case, the key factor inhibiting upgrading from 13+ year old software was cost.

When it comes to publicly-funded health services, the general public would rather their taxes be spent on front-line services that they can ‘see’, rather than on back-end computer systems and software.

As this case has highlighted though, running obsolete software can potentially put peoples lives at risk!

Why keep your MIDAS system up-to-date?

We know that some of our self-hosted customers continue to run obsolete and out-dated versions of our MIDAS room booking software.

We’ve been developing our software for close to 20 years now, and regularly release software updates. Yet, we’re aware that there some very old MIDAS systems still in operation.

We strongly encourage all customers to keep their MIDAS systems up-to-date.

For our cloud-hosted customers, we do this for you! You’ll always be running the most recent version of our software, as we seamlessly keep your system updated.

For self-hosted customers, you can quickly check for updates with just a couple of clicks. Simply login to your system and go to MIDAS Admin Options → Manage MIDAS → Update.

You’ll need an active Support Subscription in order to obtain updates. If you don’t have a subscription, or your subscription has elapsed, you can quickly purchase/renew at mid.as/renew.

Updating means that you’ll have access to all the very latest new and improved features. More importantly, ensuring you’re running the most recent version means you’re not missing out on any important security patches and updates to keep your MIDAS system safe & secure.

We’d therefore like to encourage all self-hosted customers to take a few moments to check your MIDAS system is up-to-date.

The post The Importance Of Keeping Software Up-To-Date appeared first on MIDAS - Room Booking System | Blog.

With this setting enabled, whenever a user changes their password MIDAS checks that it doesn’t appear in any known online data breaches.

Have I been Pwned?

This feature utilizes the popular 3rd party “Have I Been Pwned” service. This is a database of more than half a billion passwords which have previously been exposed in various data breaches.

Don’t worry though, your actual password is never sent to the “Have I Been Pwned” service. Here’s how it works;

1. You enter a desired new password in MIDAS.
2. MIDAS creates a cryptographic “hash” (SHA-1) of the password you entered. The first five characters of this hash are sent to the Have I Been Pwned service.
3. If hashes with the same first five characters are found in the Pwned Passwords repository, the Have I Been Pwned service responds with all these hashes.
4. MIDAS sifts through the received hashes to see if there’s a complete match with the full SHA-1 hash of your new password.
5. If a match is found, your desired password has appeared in at least one public data breach. MIDAS will then display an alert and ask you to enter a different password.

The new “Disallow Known Breached Passwords” setting in MIDAS will be enabled by default. It can readily be enabled/disabled via MIDAS Admin Options → Manage MIDAS → Security.

We’re passionate about security, and this latest improvement is just one of the ways we help keep your account and MIDAS system secure.

Interested in learning more about security in your MIDAS system? Try these links…

• Introducing our new Security Center
• The evolution of Password Storage in MIDAS
• Security Enhancements in v4.25
• Tips for keeping your MIDAS system secure
• Two-Factor Authentication in MIDAS

The post Improved Password Hardening appeared first on MIDAS - Room Booking System | Blog.

We take a transparent and pro-active approach to the security of our infrastructure and software. In fact, earlier this month we published details of how user passwords are stored within MIDAS following a data breach at one of our competitors. We also implement regular security enhancements to our software.

No technology is perfect, but here at MIDAS we believe that working with skilled security researchers across the globe is crucial in helping identify potential weaknesses in our software and infrastructure.

That’s why this week, we’re pleased to launch our new dedicated Security Center at security.midas.network

From this dedicated portal, you can …

Report a Security Concern or Vulnerability

We work alongside researchers who responsibly disclose security issues, to address such concerns and vulnerabilities in a timely manner. Our Reporting Guidelines page offers guidance for security researchers wishing to raise a concern with us.

Contact our Security Team

Our security contact page provides methods of getting in direct contact with our security team to raise a security concern in our software or infrastructure.

Read the latest Security Advisories

If a serious concern within our software or infrastructure is identified, we may issue a “Security Advisory” containing advice for customers and end-users. We will publish Active Security Advisories here: security.midas.network/advisories.

View our latest Security Audits

As part of our transparent approach to security, we’ve included a “Security Audits” section in our Security Center. Here you’ll find reports and results from both internal and external security audits on our software and infrastructure.

View our Security Changelog

Until now, we’ve been publishing two “change logs” (or “Release Notes”). One for significant major updates to our software, at mid.as/changelog. The other details interim “bug fix” updates, and may be found at mid.as/updates.

Avid readers of these change logs may notice on occasion the entry “Security Enhancements“. These are improvements we make to the security of our software, but which we typically don’t publish details of.

However, more information on these “Security Enhancements” will now be published in the Security Changelog in our Security Center. The log will also include details of security updates and improvements to our network and server infrastructure too.

View our Security “Hall of Fame”

We appreciate the time and effort that security researchers contribute. So we’ve set up a “Credits” page where we gratefully acknowledge and thank those who help keep MIDAS and our users safe.

The post Introducing our new Security Center appeared first on MIDAS - Room Booking System | Blog.