IoT Authentication is important to your IoT/ M2M devices. Recent attacks on IoT/ M2M devices have proved that the use of default usernames and passwords should now be considered a relic of an innocent connected age.
Most makers of IoT and M2M devices are well aware that basic security on their IoT devices should be present, and using a strong default username and password is a worthwhile starting point for them, as it protects IoT devices, brand reputation and limits connectivity costs. Even using the most basic authentication security, suggested below, reduces your exposure to malware and other internet based attacks.
What are the arguments for not including password and username security in IoT devices?
‘I didn’t realise it was a problem’: As you are reading this post you are now aware that there is a significant problem.
‘It is the end user’s responsibility’: While it is understandable that end users are not blameless within this, placing the entire responsibility with them would be foolish. Would you trust them to protect your brand?
As an example, I cannot remember the last time I was logging onto a friend’s Wi-Fi and the password was different from the one printed on the label. While many end users will change a password when they are prompted, remember, they are never going to worry about this as much as you should. It’s your company reputation at risk from a rogue device not theirs.
‘I cannot afford the extra set up cost’: If the security of the devices that you are selling is an afterthought with a budget to match then forget about building a reputable brand. Repeated attacks have proved that there is enough malicious intent on the internet to ensure that, although it may take time, you will be targeted.
‘I don’t have the time’: The good news is that the solutions below are a number of options, some easier to execute than others. All suggestions are less time consuming than your engineers having to deal dealing with a significant attack.
Other options to using username= root, password= root
Option 1: Tie the login details as a unique identifier of the device, place the login details within the packaging of the product. For this to work the username and password must not be easily guessed.
This is by no means perfect, it relies upon no one working out the algorithm used to create the login details, but it is much better than a single default username and password used for all devices.
Option 2: Single use login details, via a sticker on the device or similar. This prevents the end user from leaving the device with the default authentication details.
Given that it is more secure to have random login details, getting each password set by a different individual is at least prevents your entire estate being harvested and used maliciously.
Option 3: Use an out of band local channel, such as NFC or QR code to authenticate the device. This removes the requirement for human administration and authentication of the device. This solution works especially well when you own an end-to-end connectivity path.
Option 4: Build an SSL tunnel end-to-end and use this secure tunnel for remote management. This solution could use a pre-installed certificate or perhaps one created and delivered when the device is first turned on and provisioned. The use of a secure remote channel for authenticating and managing the device can remove the need for local administration privileges, thus removing a potential weakness.
Overall it is crucial to understand that there are a number of ways of avoiding using default username and passwords on new IoT devices. Dependent upon the amount of time and funding you are able to put towards security, some is always better than none for IoT authentication.
The quality and popularity of smart toys means they will feature on many children’s Christmas wish lists this year. This...
We are delighted to announce our inclusion in the new Gartner Magic Quadrant for Managed M2M Services, Worldwide”, authored by...
Continuing our drive to simplify IoT solutions for AWS, and tying in with AWS re:Invent later in November, we have...