The environment, and our combined impact upon it, is an important global issue. Every day there are new headlines highlighting the environment challenges facing our world, and ways that we can all help combat climate change and reduce our carbon footprint.
Earth Hour
Here at MIDAS you may be aware that we have previously taken part in Earth Hour and we will be taking part again this year on Saturday 27 March 2021. The aim of the campaign is to raise awareness of environmental issues and asks for both individuals and businesses alike to switch off their lights for an hour between 8.30pm – 9.30pm in their local time zone.
How MIDAS is responding
Whilst thinking about this year’s Earth Hour we have been reviewing our current environmental strategies and looking at ways in which we could further reduce our carbon footprint.
As MIDAS is an online room booking system, we’re conscious of our environmental impact. We’re also pro-active in researching ways we can reduce our impact on CO2 emissions.
As part of our research, we recently discovered the Website Carbon Calculator. The website carbon calculator uses five key metrics to estimate the carbon emissions of a website. These factors include the volume of data being transferred when a web page is viewed, the type and amount of energy used at the data center serving the web page, as well as the volume of traffic to the site.
The carbon calculator remarks that:
The average web page tested produces 1.76 grams CO2 per page view. For a website with 10,000 monthly page views, that’s 211 kg CO2 per year.
websitecarbon.com
For our own website homepage, the Carbon Calculator estimates that MIDAS is 86% cleaner than all other websites tested. It estimates that just 0.19g of CO2 is produced every time someone views our home page (1).
We also compared our website’s carbon footprint against those of other similar businesses in our sector, to see how we fare in comparison (1).
Company
Comparison against all websites tested through the carbon calculator
CO2(g) produced per view of home page
MIDAS
86% Cleaner
0.19
Roomtime
82% Cleaner
0.26
Supersaas
82% Cleaner
0.26
Skedda
75% Cleaner
0.40
Acuityscheduling
70% Cleaner
0.49
Teem
59% Cleaner
0.73
Bookinglive
52% Dirtier
1.00
Roomzilla
52% Dirtier
1.00
Getjoan
56% Dirtier
1.10
Myrendezvous
63% Dirtier
1.35
Cloudbooking
66% Dirtier
1.47
Bookitwise
68% Dirtier
1.54
Deskflex
92% Dirtier
4.45
Meetio
98% Dirtier
12.01
(1) Data correct at time of testing, and purely relates to the amount of CO2 produced per view of the homepage of each website.
As can be seen from the information produced by the website carbon calculator, there are some significant differences between some of these businesses. In some cases, viewing the home page of one of these other websites produces more than 60 times the amount of CO2 than visiting MIDAS!
Now, when choosing a room booking system, resource scheduling software, or appointment scheduler, the amount of carbon it produces probably isn’t top of your list of criteria. In fact, it may not factor in your decision making process at all!
Choosing greener online businesses
Most businesses, when focusing on reducing their carbon emissions, look to do so in “visible” ways. For instance, by reducing heating costs through better insulation, or reducing electricity costs by switching to LED light bulbs.
Reducing the amount of carbon produced by the various software products they choose is a less obvious and less “visible” action.
But when you consider the vast differences that do exist today between software vendor’s carbon production, choosing a software vendor with a low carbon footprint makes sense! Not only does it help with your own business’ green credentials, but it also – more importantly – it helps our planet.
Why choose a business that would require the equivalent of 60 trees a year to absorb the carbon it produces, when you could choose a business requiring just 2?
For a room booking and resource scheduling system committed to being green, be sure to consider MIDAS.
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 one million-plus 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 many organizations continue to use outdated software in their operations.
These may include;
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, 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 many 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 over 15 years now, and regularly release software updates. Yes, we’re aware that there some very old MIDAS systems still in operation.
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.
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.
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 stolen. 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 websites 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”. Consequently, 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. Their 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.
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.
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 continued 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.
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.
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.
