Posts Tagged: password reset

Improved Password Hardening

For MIDAS v4.26 we’re improving the password change process for users, with the introduction of a new “Disallow Known Breached Passwords” admin setting:

Disallow Known Breached Passwords in MIDAS
Disallow Known Breached Passwords

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 Change Password Dialog in MIDAS
The Change Password dialog in MIDAS
Chosen Password appears in other online data breaches
The chosen password isn’t considered secure as it appears in other online data breaches

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…


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 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.

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 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.

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.


Simplified Password Reset Process

We’re improving and simplifying the password reset process for MIDAS v4.19.

Due to the secure way passwords are stored by MIDAS, it’s not possible to “recover” a forgotten password. The only option if a password is forgotten is to request a password reset.

In the past, this process has been as follows:

  1. User clicks the “Forgot Your Password?” link on their MIDAS login screen
  2. The user then enters their email address and clicks “Reset My Password”
  3. MIDAS then emails the user with a reset confirmation link
  4. The user clicks the reset confirmation link
  5. MIDAS emails the user a new temporary password (which they’re required to change upon their next login)

We’re simplifying this process and so from v4.19 the process will instead be as follows:

  1. User clicks the “Forgot Your Password?” link on their MIDAS login screen
  2. The user then enters their email address and clicks “Reset My Password”
  3. MIDAS then emails the user with a temporary login link
  4. The user clicks the temporary login link and is prompted to enter a new password after which the user is logged in

Better Password Resets

This simplified password reset process removes the sending on two emails to users (a reset link followed by a temporary password), as just a single email will be sent. This also strengthens security as a temporary password is no longer sent via email.

This improved flow also addresses the issue of multiple password reset attempts and emails arriving out-of-order. For instance, take the following scenario:

  1. User initiates a password reset, receives an email with a reset link and clicks it
  2. Whilst the user is waiting for a new temporary password to be sent to them, the initiate a further password reset and click the reset link in that corresponding email
  3. The original temporary password email arrives, and the user attempts to use the temporary password. However, as they since initiated a second password reset request, the first temporary password is no longer valid

This caused confusion for a handful of users who’d attempted to reset their password several times within a matter of minutes couldn’t understand why the temporary password they received wasn’t being accepted.

Multiple Password Resets

The improved password reset flow for MIDAS v4.19 completely eliminates this. Even if a user initiates multiple password reset requests the links they receive via email will all permit the user to set a new password, until they have done so.

We’re sure these improvements will make it easier and stress free for users to reset their own passwords.

Along with these changes, administrators can also still specify how long password reset links are valid for (the default is 2 hours). This setting may be found via MIDAS Admin Options → Manage MIDAS → Security. For more information, please refer to the help documentation.

Of course, if a user isn’t able to reset their own password, any other administrative user who has been granted the “Can Manage Users & Permissions” user permission can reset a user password on their behalf.

Click here to continue reading about some of the other new & improved features coming in MIDAS v4.19!