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

Category: Tech Insight

Introducing our new Security Center

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: https://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 https://mid.as/changelog. The other details interim “bug fix” updates, and may be found at https://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.

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.

Strawberry Perl vs ActivePerl

Perl” is the coding language we develop our web based room booking and resource scheduling software, MIDAS, in.

Most Linux and Mac OS based operating systems come with Perl pre-installed, yet, Windows operating systems do not.

We test MIDAS on a range of operating systems, servers and platforms. Our in-house development of MIDAS is primarily within a Windows-based environment. This means that we needed to install a Perl distribution on Windows.

ActivePerl ActivePerl

When MIDAS development started back in 2005, there was really only one mainstream solution for running Perl on Windows. This was a Perl distribution named “ActivePerl“, produced by ActiveState.

The reason we liked ActivePerl was two-fold; firstly, a completely free “Community Edition” was available. Secondly ActivePerl came with a handy tool called the “Perl Package Manager” (PPM). This made installing and updating Perl modules easy. It provided a graphical interface where modules could be quickly installed, updated, or uninstalled with just a few clicks:

ActivePerl's Perl Package Manager

ActivePerl included a number of “default” Perl modules. MIDAS requires some additional modules not included within the standard ActivePerl distribution. The PPM tool allowed easy and quick install of any such modules as required.

Many of our “self hosted” customers intended to install our MIDAS booking software on their Windows-based server. Therefore, we would recommend ActivePerl due to its availability, regular updates, and ease of use.

ActivePerl Strawberry Perl

Since 2005, other Perl distributions built for Windows have come along. Perhaps the most notable of these being “Strawberry Perl“, which first appeared in 2008.

Back then we explored what Strawberry Perl had to offer when compared to ActivePerl. After evaluating Strawberry Perl, we decided ActivePerl would continue to be the Perl distribution we developed under and would recommend to our Windows-based customers.

What initially made ActivePerl better than Strawberry Perl?

When we first evaluated the newcomer Strawberry Perl in 2008 against the more established ActivePerl, differences became clear from an ease of install and use perspective.

Firstly, Strawberry Perl didn’t include a visual “Perl Package Manager”-type tool for installing and maintaining Perl modules. Rather, Perl modules required installation via the command line. On Linux-based servers, installing modules via the command line is the norm, but many of Windows-based users were less familiar with command line use. Consequently, a graphical Windows application which allowed easy install of Perl modules was preferable.

Another difference was that ActivePerl was established and more stable. Strawberry Perl was still the newcomer and felt a bit “rough around the edges”. Some Perl modules were also not fully supported or failed to install easily/correctly in Strawberry Perl.

As such, because we continued to only recommend ActivePerl to Windows customers, it was logical to continue to develop under ActivePerl ourselves. We would however keep an open mind and keen interest in the ongoing development of Strawberry Perl.

For the most part, our Windows-based customers continued to opt for our recommendation of ActivePerl. A few chose Strawberry Perl instead and were able to initially do so successfully.

Are we POSIXtive?(!)

However, around June 2010, Strawberry Perl suddenly removed a key component from their distribution which MIDAS relied on; the ability to natively work with and set Timezones. This resulted in those running MIDAS under Strawberry Perl seeing “POSIX::tzset not implemented on this architecture” errors. We had no idea why Strawberry Perl removed this functionality, or whether it was just an unintentional bug/glitch in their software. The reason for the removal of this functionality wasn’t forthcoming, or even acknowledged, by the Strawberry Perl team. This led us to initially suspect that perhaps it may have just been a bug.

This wasn’t a major problem for us, as we’d never officially recommended or supported MIDAS running under Strawberry Perl. It was of course though an inconvenience for the handful of customers who had been running under Strawberry Perl.

As a fix wasn’t forthcoming from Strawberry Perl, the solution for affected customers was either to install an older version of Strawberry Perl, or switch to ActivePerl.

By late 2010, it became clear that the developers of Strawberry Perl weren’t going to address/fix this issue. So we re-engineered our MIDAS software to work around this issue. Our next release in January 2011 once again ran under Strawberry Perl without issue.

What we learnt from all this was that Strawberry Perl still felt in its infancy and in a state of flux. We still didn’t consider it “stable” enough for use in production server environments.

We continued to recommend ActivePerl for all our Windows-based customers.

ActivePerl was in continual development, with regular releases which reasonably closely tracked the latest versions of Perl available for Linux-based servers.

Something changed…

In late 2016, we felt things began to shift and change with ActivePerl.

We began to notice that the latest versions of Perl modules stopped being offered via ActivePerl’s Perl Package Manager (PPM). Initially, this wasn’t a great cause for concern. MIDAS didn’t require the very latest version of any Perl module.

The released of ActivePerl 5.26 saw things further decline…

As you may be aware, MIDAS uses MySQL as its database. Perl therefore has to be able to connect to a MySQL database in order for MIDAS to function. The critical Perl module for doing this (DBD::MySQL) wasn’t made available for ActivePerl 5.26 via the Perl Package Manager.

This meant that MIDAS wouldn’t run for customers under ActivePerl 5.26. Customers would instead have to install the previous ActivePerl 5.24 build, which was still available for download from ActiveState.

Now, in the past following a new release of ActivePerl, it could take several weeks for Perl module updates to become available though the PPM.

So we waited… and waited.. yet still no DBD::MySQL module appeared for ActivePerl 5.26. ActivePerl 5.26 became useless for any application like MIDAS which need to connect to a MySQL database!

In our view, ActivePerl declined from there; in order to download ActivePerl an account was now required on their website. Additionally, they discontinued Perl Package Manager. Instead users had to “custom build” their own ActivePerl package in the cloud with the modules they need.

ActivePerl’s development started to lag behind Perl itself. For example, at time of writing, the latest official version of Perl available is 5.30.2. The latest version of Strawberry Perl available is also 5.30.2. However, the latest version of ActivePerl available today is 5.28.1 – nearly 2 years behind where Perl is currently at!

Then in 2019 ActiveState’s website was reportedly hacked.

Doubts began to arise over ActiveState’s commitment to continuing to continue to provide Perl and a free “community edition”. Their focus seems to have shifted more towards monetization and on their Python language products instead (as evident from the majority of their recent posts on Twitter)

Why we moved to Strawberry Perl?

These developments were a worrying trend for us. This is why last year we began equally promoting and recommending Strawberry Perl alongside ActivePerl on our server requirements page. We also provided a helpful step-by-step guide for installing Strawberry Perl, to complement our previous guide for installing ActivePerl.

Strawberry Perl has certainly come a long way since its first release. It’s now very stable, is passionately developed, and closely tracks the official version of Perl with frequent releases. Best of all, it remains completely free!

Whilst there’s no “visual” tool to install Perl modules as there was with the PPM under ActivePerl, installing modules under Strawberry Perl is still straight forward. We’ve found that the latest modules are always available (including DBD::MySQL!)

Many previous ActivePerl users around the world have already made the switch over to Strawberry Perl. At the start of 2020, we also moved all our development from using ActivePerl’s distribution or Perl to Strawberry Perl.

Should I choose ActivePerl or Strawberry Perl?

If you’re considering a self-hosted edition of MIDAS (remember that we also offer a cloud-hosted edition too!) for install on a Windows-based server, whilst we still presently support both ActivePerl and Strawberry Perl on our website we would strongly recommend you choose Strawberry Perl.

If you must use ActivePerl, then we’d suggest getting your hands on 5.24, although this is now four years old, and we’re big advocates for keeping server software up to date. So going forward Strawberry Perl would be our preferred option on Windows.

In this blog post, we’ll take a look at SPF and why its important in ensuring email from your MIDAS room booking system is reliably delivered.

SPF stands for “Sender Policy Framework” and its purpose is to prevent unauthorized people from forging your e-mail address and pretending to be you. SPF has been around for a number of years now, but in recent times has been growing in popularity as more and more websites and email providers start enforcing it.

As our MIDAS web based room booking systems are capable of sending email on your behalf, it’s important to understand how SPF works and how it can help solve email delivery issues in MIDAS.

Take for instance the following example Scenario:

  • Your MIDAS system is running on domain “A” (i.e. your-organization.mid.as)
  • Your MIDAS system is configured to send emails to appear as though they are sent from an email address belonging to domain “B” (i.e. your-organization.com)
  • An email is sent from your MIDAS system to a recipient with an email address on domain C

In the above example, the receiving mail server for domain C queries the SPF record on domain B to check whether domain A is authorized to send mail on behalf of domain B. If it isn’t the email is rejected.

An SPF record is simply a TXT record in a given domain’s DNS, and a simple example may look similar to this:

v=spf1 +a +mx ~all

The format of an SPF record begins with a version number; the current SPF version is “v = spf1”.
Following the version string, any number of expressions may be included which are evaluated in the order they appear. These consist of an optional “qualifier” (+, -, ~, or ?) and a “mechanism” (all, a, mx, ip4, or include). The first mechanism that is matched in the SPF record determines the result of the entire valuation of the SPF record.

Qualifiers:

QualifierResultDescription
+PassDefines an authorized sender
(If no qualifier is specified, + is assumed)
FailDefines an unauthorized sender
~SoftFailDefines an unauthorized sender
(however it may not notify the sender that their email failed)
?NeutralDefines a sender whose legitimacy isn’t determined
(In such instances, sending is allowed)

Mechanisms:

MechanismApplies if…
allalways
aAn A (or AAAA) record of the polled (or explicitly specified) domain contains the IP address of the sender
mxAn A (or AAAA) record of the polled (or explicitly specified) domain contains the IP address of the sender
ip4The specified IPv4 address is the IP address of the sender or of the specified IPv4 subnet which contains it
includeAn additional SPF request for the domain specified in the include statement contains the IP address of the sender

SPF records cannot be over 255 characters in length and cannot include more than ten “include” statements.

Example SPF record:

v=spf1 +a +ip4:1.2.3.4 -ip4:5.6.7.8 +include:somedomain.com ~all

In the above example:

  1. Email delivery will be allowed if it originated from the same domain it was sent (+a).
  2. Email delivery will also be allowed if it originated from the specific IP address 1.2.3.4
  3. Email delivery will be rejected if it originated from the IP address 5.6.7.8.
  4. Email delivery will be allowed if it matches the rules defined in the SPF record on “somedomain.com”
  5. All other email sources will be softly rejected (~all)

Bringing it back to MIDAS…

If you run a cloud-hosted MIDAS system at the domain “your-organization.mid.as”, your organization’s own website is “your-organization.com”, and you wish to allow your MIDAS system to send email on behalf of addresses @your-organization.com, then you should setup/modify an SPF record on your-organization.com.

This SPF record would authorize your hosted MIDAS system to send email on behalf of your organization. Failing to correctly set an SPF record for your domain may mean that emails sent from your MIDAS system may not reach recipients.

For our hosted customers, you can simply include “include:_spf.midas.network” in your-organization.com’s SPF record. Your new/modified SPF record may then look similar to this:

v=spf1 +a +mx include:_spf.midas.network ~all

In the above example:

  1. Email delivery will be allowed if it originated from the same domain it was sent (+a).
  2. Email delivery will be allowed if it originated from the same mail server as it was sent (+mx)
  3. Email delivery will be allowed if it matches the rules defined in the SPF record on “_spf.midas.network”. This will allow your hosted MIDAS system to become an authorized sender of email for your domain.
  4. All other email sources will be softly rejected (~all)

Remember, SPF records are simply TXT records within your domain’s DNS. If you’re not sure how to set/modify DNS records for your own domain, you’ll need to defer to the domain’s administrator, registrar, or hosting provider who should be able to assist in making the necessary adjustments to your domain’s DNS record

Further reading from our Knowledgebase:.