9 Jun 2023
•
8 min read
A door and doorbell are just like any other system, that users interact with, and must be maintained – especially if in a shared space. They are indeed simple concepts that do not need re-inventing, but if you ever worked in a small office you might know that managing access with keys, codes, and even cards is cumbersome. Whenever the company scales, someone will end up having the sole responsibility of managing access, for example via a security team. We are not at this scale and do not intend to give anybody more work. The purpose of our setup is to make things simple both for all employees and management.
Traditional metal keys are one of the best and simplest access control mechanisms - for small places like your home. Everyone knows how they work, they are cheap, available to everyone and they don't need batteries or internet. But with a bigger user base, traditional keys pose an obvious risk and management hassle: when lost or stolen, they cannot be revoked, and all the keys need to be replaced. Even day-to-day operations, like making an extra copy, require a visit to the locksmith. Naturally, this is not an option as soon you scale from being a micro-company.
Pin code is another method of access control that is simple to install and maintain. Although it cannot be lost, it is more likely to become shared between users. It is also less convenient as you need to memorise one more password, and typing it might be time-consuming.
Key fob/entry cards are the standard for businesses of any size. It solves most of the management problems encountered by traditional keys. And it is pretty simple for the final user.
We have a door with an electromagnetic door lock that supported key fob/entry cards and pin codes. It works (still does) okay - the main problem was the management hassle.
We won't go very far on the specifics of the systems in use, but here's what we had to do to add a user to the system:
Login to a remote Windows machine;
Open up a traditional desktop application;
Manage users and then “sync” with the device.
Adding a card/key fob is even more complex: you have first to scan the card on the device (near the door), then fetch the logs in the software to get the card identifier. Theoretically, you could run this program with a card reader attached to the computer directly, but that would require Windows with direct network access to the door lock. Frankly, both are quite complex.
As you can imagine by now, in an environment where we focus on shipping products with great experiences, this is something no one wants to deal with. Not only was the onboarding tedious, but obviously, past employees were always forgotten and not removed from the user base.
We treated this like any other systems problem, similar to the ones we encounter every day at Significa. Indeed, we had a system that was terrible to use and was potentially a security hazard: we wanted something simple that just worked.
In an ideal scenario, for a company our size, users would be able to self-service themselves getting access to the door when they arrive, and they would somehow be removed automatically as soon they no longer work here.
We searched for a few options, but were unhappy, specially because we don't want to get into big ecosystems, corporate solutions or make complex installations.
Over time I've seen many different door systems, ones cooler than others, still the management is always annoying, especially if you are the one maintaining the access control.
As you can imagine by now, we developed our own custom solution. We kept the existing hardware to simplify things, just made it more user friendly. It was quite simple and we believe that the solution is the best compromise between security and simplicity.
You can open the door with any device with internet access, your phone, watch or, for the geeks out there, with your favourite terminal. We primarily use Apple shortcuts.
Access control is automatic, and new employees can get access to the door by following instructions in an onboarding document. Access is automatically revoked whenever they leave Slack, our communication tool.
Quite simply, first-timers just need to use Slack’s slash commands to get a secret. The secret is unique for each user, and will be used to configure the integration.
Afterwards, users can use any of the of the pre-shared shortcut, for example the Apple shortcuts or IFTT. We provide a nifty Apple shortcuts link that can be seamlessly added and will prompt the secret during installation.
This integration can be used with anything that can do an HTTP request. Phone, watch, desktop, laptop, you name it.
The doorbell is connected to Slack, meaning whenever you ring it, it takes a picture and sends it to a specific Slack channel, allowing anyone to open it directly with an interactive Slack message . So, if you are anxiously waiting for a package, you can join this channel and make sure you are the first to click the Open Door button.
Our setup might look complex, but connecting all this is actually pretty straightforward.
At the centre of everything is our Python + Flask + Peewee application. In essence, it's what connects it all up.
In our Slack workspace, there's an application installed that sends us HTTP requests whenever a user performs slash commands. We also use it to post doorbell messages, retrieve the user directory and invalidate tokens for users that have left Slack.
Thankfully our Netatmo doorbell came with a nifty API, and we are able to configure Webhooks for whenever someone rings the doorbell.
Shelly is the IOT relay we added to our existing door setup, connecting it to the internet. We just need to send a request to their cloud and the door will open. We thought about making the requests directly to the device, eliminating the third-party cloud, but that would require some kind of server running, which is one more thing to manage - maybe in the future.
This decision, at first, might seem strange, but integrating with Slack means that we only have one third party service. From the start wanted to make the doorbell ring in Slack, so a Slackbot was needed. Managing Slack applications is very simple, and the interaction is surprisingly great too! Zero UI development, just develop as you would for a CLI application. Although Google Workspace makes sense if you want to go all out in the source of truth for the identity provider, our Slack users are already in sync via their integration - it is one less piece in the puzzle to manage: apps, permissions/authorisation, OAuth2, multiple environments, etc.
As with any modern software development project, we have multiple environments, in this case, staging, production and a local environment. We have it all: a staging database, slack application, slack workspace, and to top it all, a miniature door. We use GitHub actions to build test and deliver the software to Fly, our container hosting provider.
We were actually quite lucky to find that the power to the door was already provided by the UPS, meaning that it should last a while in case of a power failure and will eventually become unlocked. This is quite normal as this setup is considered a Safety-First (vs the opposite Security-First). For those sneaky ones reading: we do have a gate outside this door that is closed at night, plus an alarm system in place.
The internet is also backed by UPS – the webserver and database are redundant in two Fly.io regions. In case all fails, we would have to use a backup code or card to open the door from the outside. That's the main reason we kept the existing system. It works entirely offline, and we can keep a few codes for when all fails.
From the inside, we have a switch that opens the door at any time.
Secrets are extra long, maybe too long to be honest, and are stored hashed with SHA256 – so they cannot be recalled or read from the database. Whenever the user, for some reason, needs to rotate the secret, they can run the command /regenerate-door-secret.
Note that we do not need password hashing algorithms like Argon2
, Bcrypt
or PBKDF2
because we know that the input is of big entropy, generated with a cryptographically secure number generator (not a user-generated password).
Also, Slack does not index and forgets this message since the response_type is set to ephemeral.
This is a double-sided sword, it's cool to be able to open the door remotely, but we want to avoid doing it by accident. Thus, the shared Apple shortcut template uses geolocation to check if you are near the office and prompts you if not.
As you can see, there isn't a fancy geofencing system. It just checks if you are on the office's street. This restriction runs in the device, meaning that the system we built has nothing to do with geolocation. Restrictions must happen in the automation application, the server has no knowledge of the end user's location.
That's it, I probably went too in-depth for most readers, but I bet some of you would like even more details.
All in all, we built a fantastic experience on top of an existing system with little work and complexity. It just works and has been running with no problems for more than a year. It is extensible – not only can it be used in multiple ways, but it is also a cool playground for us to try new things.
Francisco Marques
CTO
Francisco is the CTO at Significa but more importantly, he’s our office keeper. The Hagrid of Torrinha 154. He always keeps a hammer and a handful of nails by his desk, just in case.
Nuno Polónia
Front-End Developer
18 October 2024
•
7 min read
Significa
Team
30 September 2024
•
5 min read
Alec Norton
Operations Manager
27 February 2024
•
2 min read