Mandating Two Factor Authentication

As many of you may know, we’ve been championing the use of Two Factor Authentication (2FA) in agileBase for a number of years and gradually increasing the ‘nudges’ towards this – prompting and requiring 2FA for tasks such as exporting or bulk editing data.

We also keep an eye on what are the best technologies – for example we recently removed the ability to use SMS text messages to receive 2FA codes, as that mechanism has been found to be insecure.

Today, we continue that trend by adding an option for a company administrator to require the use of 2FA for all users.

If 2FA is required, any user who logs on will be asked to set up 2FA, if they haven’t done so already. If they don’t do that, they will not be able to go on to use the application.

A couple of common questions are

  • what about people who can’t use 2FA because they can’t use a phone at their workplace?
  • what happens if someone loses or breaks their phone, that they were using for 2FA?

Firstly, phones aren’t the only devices that can be used as the ‘second factor’ to authenticate with. There are actually many desktop applications that can serve the same purpose. In fact, here at agileChilli, we use 1password.com – this password wallet also generates your 2FA codes.

Secondly, if someone does lose a device and therefore loses the ability to authenticate, it is possible for an administrator to disable 2FA for their account. If 2FA is required by the company (with this new setting), that means the next time they log in, they will be prompted to set it up again.

Note: administrators need to be careful to make sure they’ve verified the identity of anyone requesting their 2FA be disabled.

Remember, with 2FA on, people will only be prompted for their code when they log in from a new device or location.

Turning on the option to require 2FA

We do recommend that every customer considers doing this. In the administration interface, edit the company and tick ‘mandate 2FA’.

A new filtering option

An option to include blank values has been added, which can be applied to any new or existing view filters. This greatly simplifies many view filtering tasks.

Normally filters such as ‘date is up to 7 days ago’ exclude blank values, which is often not wanted as it will exclude any records where the date field has not been filled in yet. Now you can just tick ‘or is blank’ for the filter to include them. Previously accomplishing the same thing would have required creating a calculation such as

{date field} is null or {date field} > (now() – ‘7 days’::interval)

then filtering on that, which is not something that’s particularly user friendly for new learners, and is annoying even for seasoned developers.

This type of filter is commonly required when e.g. sending email notifications. You often need to send a notification for events, tasks etc. which either haven’t had notifications send in the past X days, or have never had a notification send (i.e. the ‘last notified’ field is blank).

Efficiency measures 

Finally one other update is more behind the scenes, but is worth mentioning because it could possibly affect some users.

An efficiency improvement measure has been added, so that when a record update is requested, that update won’t actually be done if the data to save is exactly the same as the data already in the database.

That wouldn’t usually happen in everyday use of course, but it can in particular situations where automated updates are done, either by a workflow or from API requests. When that’s the case, this change can reduce the workload on the server – not only due to the work necessary to update the records themselves, but also related things such as

  • adding log messages – logs can grow very large!
  • kicking off workflows
  • forcing views to refresh caches, as they think that underlying data has changed

This should have no effect on the vast majority of people, beyond some general performance improvements, however the one case it’s possible could be affected is when you set a workflow or API call to update a record specifically to update the ‘last changed’ date of that record, e.g. in order to kick off a workflow. If you do that, you’ll now need to ensure that you include data that actually does change the record, otherwise it will have no effect.

Thanks go to The Safeguarding Company for requesting this month’s 2FA update. If any customer has any request for further functionality in any area, please do get in touch too.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s