Latest News - July 2020: MIDAS v4.25 Now Available | COVID-19 Support

MIDAS v4.25 Out Now!

If you’ve been following our blog in recent weeks, then you’ll know that we’ve been busy during the UK lockdown. We’ve been hard at work at our next update to MIDAS v4.25, which is out now! For this update we’ve added dozens of new features and improvements, which we’re really excited about!

Highlights of MIDAS v4.25 include:

How To Get MIDAS v4.25…

New To MIDAS?

We continue to be committed to fair and accessible pricing for all organizations regardless of size.

We’re totally upfront and transparent about our pricing structure, and you can purchase MIDAS v4.25 securely through our website and be up and running in no time!

“Self Hosted” Customers:

Self-Hosted customers with active Support Subscriptions will be able to update to v4.25 in the coming weeks. It only takes a couple of clicks – simply log in to your MIDAS system and go to MIDAS Admin Options → Manage MIDAS → Update.

If no update is available, please check back again in a few days time, as we are staggering updates for self-hosted customers over the next few weeks.

“Cloud Hosted” Customers:

Cloud-Hosted customers don’t need to do anything! – All our active Cloud-Hosted MIDAS customers were automatically updated to this latest version of MIDAS this past weekend (4-5th July)

Important Information For Existing Customers Regarding Invoicing in v4.25

We’ve made some changes to invoicing in MIDAS for v4.25, and we’d like to draw your attention to one specific change;

If you’ve previously manually created or modified invoices in your MIDAS system, and in doing so altered totals with the auto-recalculation option disabled, then your previous invoices may look slightly different after being updated to v4.25.

You may see the addition of balancing items or balancing credits listed on previous invoices. These may be added in some instances to ensure that the items appearing an each invoice match the invoice’s total.

For more information on this, please see our KB article: What are balancing items or credits on invoices?

If you have invoices where you’ve modified line totals without allowing MIDAS to correctly recalculate the grand total, and you wish to retain these invoices their current state (without balancing items/credits being applied), we suggest that you print these invoices prior to updating to v4.25.

It is important to note however that the presence of balancing items or credits on previous invoices will not affect an invoice’s total.

Should you have any questions or concerns in this regard, please don’t hesitate to reach out to us and we’d be happy to help!


Thank you for your continued support of our software during this unprecedented period of global uncertainty. Please remember that if you’re an existing customer affected by the current situation, we’re here to support you!

Earlier this week one of our competitors revealed that they had suffered a significant data breach. As part of this breach, “hashes” of their user’s stored passwords were obtained. The vendor asserts that user passwords were hashed using “an irreversible hashing algorithm based on SHA256“. Some security experts question just how secure SHA256 is by today’s modern security standards. Indeed, SHA256 hasn’t been considered “best practice” for password storage for some time.

So in light of the recent breach at one of our competitors, we thought we’d provide an in-depth look into how own approach to password storage has continuously evolved over the years…

December 2005

We first began work on our MIDAS room booking software back in 2005. In those days the threat of passwords being stolen was relatively low. The majority of web sites and web applications simply stored passwords in plain text. It was also common place to allow a user to “recover” a password that they’d forgotten. In order to achieve this, passwords needed to be stored in a simple manner (such as plain text) which allowed them to be easily retrievable.

In those early days of our software, this is also how user’s passwords were initially stored within a MIDAS system. Passwords were stored in plain text, in files with a .dat extension. The “.dat” extension was chosen as back then, most web servers didn’t know how to handle these files. As such, .dat files were typically not accessible through a web browser. This provided a certain degree of security, in that the only way to view the contents of these files would be for a hacker to gain unauthorized server access.

September 2009

A few years later (for MIDAS v2), we improved password storage by instead “encoding” passwords in these .dat files. No longer were passwords stored in “plain text” but were instead stored in an “obfuscated” way. This made them difficult for humans to read, but still allowed MIDAS to “decode” and “un-obfuscate” them. In turn, this allowed user’s to recover their original password if they forgot it.

The process for validating passwords in v2 was essentially: Does the raw password entered by the user match the decoded/un-obfuscated stored password?

August 2012

Now, “encoding” is not the same as “encryption”, and in keeping with the times, in 2012 with the release of MIDAS v4, we completely overhauled password storage in our software.

We implemented a cryptographically secure and randomly salted one-way “hashing” algorithm, named “SHA-512“.

A “salt” is a generated string added to each password as part of the hashing process. A random salt means an attacker would need to crack hashes one at a time using the respective salt, rather than being able to calculate a hash once and compare it against every stored hash. This makes cracking large numbers of hashes significantly harder, as the time required grows in direct proportion to the number of hashes.

“Hashing” passwords in this way was far more secure, as the passwords themselves were never stored, only their resulting “hashes”. This made it technically impossible to “retrieve” an original password from a password “hash”. As such, the ability for users to be able to “retrieve” a forgotten password was lost. Instead, if a user forgot their password, the only option now would be to reset it, as the original password couldn’t be recovered.

In 2012, SHA-512 was widely considered “best practice” as one of the most cryptographically secure ways of dealing with passwords.

The process for validating passwords in v4 was essentially: SHA-512 hash the raw password entered by the user and compare this with the previously stored password hash to check they match.

Version 4 of MIDAS also introduce further enhancements in relation to password security; the ability for user accounts to be automatically locked after several failed login attempts.

This was important, as it helped prevent “brute force” password attacks.

A “brute force” attack is when a large number of passwords are tried until the correct one is found. Sometimes referred to as a “dictionary attack”, a malicious hacker would apply a “word list” of thousands if not millions of words and word combinations to login forms.

By limiting the number of incorrect login attempts that are allowed before a user account becomes automatically “locked out”, the threat of “brute force” attacks on a user’s account was mitigated.

September 2015

With the release of MIDAS v4.10, we introduced optional two factor authentication (2FA) to the login process.

April 2016

As mentioned earlier, SHA-512 hashes introduced with MIDAS v4 were “randomly salted” to further increase their security. In order to generate these random salt, MIDAS utilized the built in “rand()” function of Perl (Perl is the coding language which MIDAS is written). “rand()” generates random numbers, but these random numbers in themselves cannot be assumed to be sufficiently random for use in cryptographic applications.

So for MIDAS v4.11, we improved the “randomness” of these “salts” by utilizing a Perl module named “Math::Random::Secure”. If this module was installed on a server where a MIDAS system resided, MIDAS would use this module to generate Cryptographically-secure random numbers for use as SHA-512 salts.

July 2016

In July 2016 to coincide with the release of MIDAS v4.13 we introduced a password “block list” in MIDAS. The top 1000 most common passwords in use around the world are now banned from being used in MIDAS.

In addition, we also prevented using passwords considered “very weak”.

April 2017

The world of cryptography is changing all the time. Whilst our software has been in active development for over 15 years, we’ve continue to take a pro-active approach to security, including password storage.

That’s why in April 2017 (starting with MIDAS v4.15) we migrated from using SHA-512 to the more the modern and even more secure “bcrypt” for password storage.

Why did we do this?

Well, even though SHA-512 was still considered “secure”, its hashing algorithm is designed to be fast.

But surely faster is better?!

No! When it comes to password hashing, slower is actually better! We’ll explain why…

As hashing is “one way”, original passwords can’t be “recovered” from a resulting password hash. Instead, in order to validate a password it must itself first be hashed and the resulting hash compared to the stored hash.

Let’s assume that a malicious hacker were to obtain a password hash. If the hashing algorithm used was computationally “fast”, it would allow a computer to potentially compute the hashes of hundreds or thousands of passwords every second. It therefore wouldn’t necessarily take a powerful computer that long to “find” the original password if the user used a weak password.

“bcrypt” is different. It is computationally expensive. That means it takes a significant length of time to compute each hash.

As technology improves, computing power generally doubles every 18 months. This is known as Moore’s Law.

bcrypt takes this into account by allowing control over how “computationally expensive” its hashing is. This is know as its “work factor”. MIDAS v4.15 introduced a bcrypt work factor of 10, as this was widely considered by security expects to be sufficient at the time.

July 2020

Three years later, and the current accepted “best practice” has evolved as computers have become more powerful. A “work factor” of 12 is now recommended.

The time taken to compute a bcrypt hash effectively doubles with each increase in work factor – so a work factor of 11 would take twice as long to compute a hash for than a work factor of 10.

As such for MIDAS v4.25, we’re transparently increasing the bcrypt work factor from 10 to 12. User’s won’t see any difference, as stored password hashes will be automatically migrated.

For v4.25 we’re also banning passwords considered “weak” in addition to “very weak”.

We’re also dropping usage of the “Math::Random::Secure” Perl module introduced with MIDAS v4.11 in 2016. MIDAS has been utilizing the “Math::Random::Secure” module where available to ensure that random numbers generated by MIDAS were cryptographically secure.

Whilst the module still functions, its developers haven’t updated it in over three years. “Math::Random::Secure” also depends upon another module (Crypt::Random::Secure), which itself depends upon another module (Any::Moose) which has since been deprecated.

So for this reason, and also for performance reasons, MIDAS v4.25 now defaults to using the more modern module “Crypt::PRNG” where available instead.

Summary

We take a very open and pro-active approach to security.

As you can see from the timeline we’ve outlined above, password storage and security has significantly evolved over the past decade and a half within our software. It will continue to evolve in the future too. What’s considered “cryptographically secure” in today’s world may not still be so in a few years time. We’ve moved with the times and we’ll continue to do so.

If you’re considering a new room booking system, or indeed any other web/cloud based software or service; make sure you ask the vendor about their approach to password security and storage!

If the vendor won’t tell you how passwords are stored… for “security reasons” – challenge them! (or run a mile!) “Security through obscurity” simply isn’t good enough! If a vendor is storing passwords correctly and securely, they should have no concerns outlining the method by which they are doing so.

If a vendor is still storing passwords using “Legacy Algorithms” (like SHA-256) – challenge them to move to modern algorithms instead!

Data Breaches are sadly an increasingly common part of life. The best thing software vendors can do (aside from taking steps to prevent breaches in the first place) is to ensure sensitive data like passwords are securely encrypted in ways that would make the data worthless to hackers were it ever to be obtained.

Security Enhancements in v4.25

Security is our number one priority here at MIDAS. We constantly strive to ensure our software remains secure, and provide users with a range of tools to help keep their MIDAS accounts and data secure.

We’re further enhancing security in MIDAS v4.25 and introducing a new admin setting.

New & Unfamiliar Login Notifications

A new “Alert users upon logins from unfamiliar devices” setting is located under MIDAS Admin Options → Manage MIDAS → Security.

With this setting enabled, a user account logged into from unfamiliar an browser/device, will trigger an automated email notification to the account holder.

Email Notification alerting user to an unfamiliar login to their account
Email Notification alerting user to an unfamiliar login to their account

This email notification is customizable through a template via MIDAS Admin Options → Manage MIDAS → Templates. The default notification provides details of the browser, operating system, and IP address of the new login. It advises that the notification can be safely ignored if the new login was genuine, or what to do if the user doesn’t recognize the login.

Obviously for these email notifications to be sent, your MIDAS system must be correctly configured for sending email.

Other “Under The Hood” Security Enhancements

You’ll often see “Security Enhancement” in the changelog for our MIDAS software. This is nothing to worry about, and it’s part of our pro-active approach to security.

We routinely make small changes to improve and “harden” our software against a variety of threats.

One of the security enhancements we’ve made in v4.25 is to drop usage of the “Math::Random::Secure” Perl module. Perl – the language that we develop our software in – is capable of natively generating random numbers. MIDAS uses random numbers for a variety of things, including password generation and unique session tokens. However, random numbers natively generated by Perl are not “cryptographically secure”. As such, we’ve been utilizing the “Math::Random::Secure” module to ensure that random numbers generated by MIDAS were cryptographically secure.

The developers of “Math::Random::Secure” haven’t updated it in over three years. Whilst the module still functions, it depends upon another module (Crypt::Random::Secure), which itself depends upon another module (Any::Moose) which has since been deprecated.

So for this reason, and also for performance reasons, MIDAS v4.25 now defaults to using Crypt::PRNG instead. If this Perl module isn’t available on your server, MIDAS will simply revert back to Perl’s native random number generator. However, it’s really easy to install Perl modules, and so for enhanced security we’d recommend installing Crypt::PRNG.

Dropping TLS 1.1 support for cloud-hosted customers

TLS stands for “Transport Layer Security” and is a mechanism used to facilitate secure connections and communications over the internet. To date, there have been three versions of TLS, each more secure than the last. The latest version of TLS is 1.3. The original TLS 1.0 version is considered “weak”, and no longer supported by modern browsers. We previously dropped support for TLS 1.0 on our servers back in July 2017.

To coincide with the release of MIDAS v4.25, we’ll be dropping support for TLS 1.1 connections to our client servers. Our client servers will continue to support both TLS 1.2 and TLS 1.3 secure connections.

Dropping TLS 1.1 support should have no noticeable impact for regular users of MIDAS. We’ve already dropped TLS 1.1 support on our website. If you’re reading this post, then you’ll still be able to access your hosted MIDAS system once TLS 1.1 support is dropped.

However, if you’re a cloud-hosted MIDAS customer utilizing the optional MIDAS API then you may need to take action. Please ensure that your applications and the underlying programming language you develop in can support (and are correctly configured for) TLS 1.2/1.3 connections.

If your applications/programming languages do not support at least TLS 1.2, your MIDAS API calls will begin to fail once we disable TLS 1.1 support.

Please refer to the vendor of your programming language if you’re unsure whether it supports TLS 1.2/1.3, or for assistance enabling such support in your development environment. This doesn’t affect API users interfacing with a self hosted MIDAS system.


These are just a few of the new and improved features for MIDAS v4.25. Please see this post for details of other new features you’ll find in v4.25.

Reddit You can also ask questions and discuss the new features of v4.25 over on Reddit.

If you’ve been following our recent posts, you’ll know that we’re introducing a whole host of new features for MIDAS v4.25. Many of the new and improved features in v4.25 relate to invoicing.

There’s a lot to take in, so we thought it would be useful to summarize the new and improved invoicing features of MIDAS, with links to posts with more information.

In addition to the above, there’s a handful of smaller invoicing improvements worth noting too:

Updating Finalized Invoices Now Allow Updating Visible Notes

Once an invoice is first printed, or emailed to the client, MIDAS considers the invoice “finalized”. The content of finalized invoices cannot then be changed. However, MIDAS does allow you to update the paid status of the invoice at any time. Additionally, you can also add internal notes at any time time. Internal notes are not visible to clients on actual invoices.

From v4.25 we’re now also allowing you to modify the “visible” notes section on invoices – even after they’ve been finalized!

Multiple Identical Items On Invoices Are Now Consolidated

MIDAS now consolidates identical items on invoices. For example, say you’re adding a booking across two venues (rooms), each of which requires a “CD Player” resource in it.

When invoicing for these bookings, MIDAS would previously list the two venues separately and the two resources separately.

Now, MIDAS will identify these instances and combine items accordingly. So now instead of having two lines on a invoice both for a “CD Player” and both with a quantity of 1, they’d be a single “CD Player” line with a quantity of 2.

Itemized Invoice Notes No Longer Include Empty Notes

The visible “Notes” section on invoices can be configured to be automatically populated with the content of a booking field. For instance, you could set the “Booking Notes” to automatically appear in the “Notes” section of the client’s invoice.

If multiple bookings appear on the same invoice, it could get confusing as to which booking the invoice notes relate to. That’s why we’ve previously provided an “Itemize Notes” option. When enabled, each item on the client’s invoice with an associated note is indicated with a reference number. This appears on the invoice line it relates to, and then also in the Notes section below.

If an item had no notes associated with it however, it would still be given a reference number. This could be just as confusing if none of the bookings had notes. You’d end up with a string of meaningless numbers in the Notes section, like [1] [2] [3] [4] [5]

We’ve sorted this out for v4.25! Now, only bookings with notes will be numerically referenced if the “Itemize Notes” option is enabled.


These are just a few of the new and improved features for MIDAS v4.25. Please see this post for details of other new features you’ll find in v4.25.

Reddit You can also ask questions and discuss the new features of v4.25 over on Reddit.