Applying multi-factor authentication to connected devices is tricky, but it can and should be done, especially on the administrative side of things.
Regular readers of the Get Connected Blog will know that we frequently talk about how security must be baked in to the foundation of every product. Networks are only as secure as the weakest link.
Now that homes, factories, and vital infrastructure are being connected, security has never been more important.
Simply put, multi-factor authentication (MFA), of which two-factor authentication (2FA) is the most well-known, is a way of combining more than one level of security to control access to something.
From a simple SMS code sent to a trusted smartphone to a code generator that creates single-use access codes, MFA is already used in many web applications. For a good example, look no further than our own Nordic DevZone.
What makes MFA more secure is the focus on a genuine two-factor approach, using something only you know and something only you have.
Read more: Authentication 101: A Question of Trust
In regular authentication schemes, only one factor is used: The knowledge factor where you are asked to present a username and a password. While secure enough for many purposes, non-complex passwords can be hacked.
MFA adds a layer of security on top with the possession factor. It's not enough to know something - you've also got to have something. Typically this is done via the smartphone.
There’s also a ‘something you are’ approach, which includes biometric details such as fingerprints, retina scans and facial or voice recognition. While this may seem a little far-fetched, fingerprint ID has already been replaced by facial recognition ID in many of the newer smartphones, something which many apps have been quick to adopt for extra authentication.
For MFA to work in the IoT it must be as simple as possible. The amount of inconvenience that users will bear depends on what is being protected. People are more likely to accept the inconvenience of carrying around a code generator for online banking than they will for a social app, but with the rapid rise of the smartphone even that's fast becoming a stretch.
The tricky aspect for IoT is that many smart devices don’t have a screen and/or a keypad to enter a password. At the user level, it’s vital therefore to consider both what is necessary and what is practical. Security is important, but too much, or the wrong type, is often worse than no security at all.
There are many cases where MFA isn’t suited for IoT devices at the user level, but a good argument for implementing MFA can always be made at the admin level.
Implementing an MFA system for the initial hardware commissioning process is also worth considering, depending on the level of risk involved. If someone can add a new lightbulb to a network at the touch of a button, someone else could also add a malicious device just as easily. Remember the connected fish tank that led to a casino hack?
Read more: Secure IoT commissioning: How hard can it be?
Requiring a specified Bluetooth beacon or NFC dongle to be present reduces this possibility, as does using an SMS code, although this option requires a back-end/cloud infrastructure. You should also bear in mind that the device used for access and the device used for authentication should be different.
If you implement a system that generates a login code sent via SMS to a smartphone, and you can access the system using an app or web browser on that smartphone, you reduce the MFA system back down to a single factor. In these cases, requiring a traditional password or PIN-code that the user has to remember is a common solution, as used by some online banking platforms.
Adding MFA to your products is important but if it falls outside of your area of competence then there are various trusted third parties out there who can offer you a secure solution. There’s no need to reinvent the wheel.
We already mentioned the biggest player, Google Authenticator, which offers a versatile MFA framework with a user app available for both Android and iOS. It’s what we use on the Nordic DevZone.
This article was first published October 2018