The dangers posed by universal default passwords (UDP) in consumer Internet-of-things (IoT) devices is not hard to recognize. As the name suggests, a UDP is a password used as a default setting for a mass-produced consumer device. Whether the UDP is a weak password (ex. “12345”) or something more complicated, once it is known by a malicious actor all devices that share the password are vulnerable to attack. Similarly, even unique default passwords for devices that are based on a formula or pattern pose similar risks (ex. “1111” for one device, “2222” for another, “3333”… etc.) when they can be readily decoded.
UDPs not only put individual devices at risk they also make attacks easier to conduct at scale as one piece of malware can use common passwords to attack many devices at once. This was how the “Mirai” botnet was famously able to grow so rapidly, successfully targeting consumer products with just 60 known default or easy-to-guess username/passwords combinations; a strategy which left more than 500,000 IoT devices vulnerable to attack in recent years.[1] Given this demonstrable risk, manufacturers should not utilize UDPs or simply put the burden on consumers to change weak default passwords on their devices. The practice itself needs to be put to rest.
Consumers have a right to expect better security, especially when IoT devices are often targeted by malicious attacks within minutes of being connected to the internet.[2] So let’s quickly explore why this continues to be a challenge, and what types of solutions manufacturers can pursue as alternatives to UDPs.
Why do manufacturers still use UDPs?
UDPs can make some things easier. Despite the risks, UDPs have upsides when it comes to things like account recovery and enabling legitimate remote access by vendors. Some organizations feel default passwords are necessary in addressing when a user forgets his/her password to ensure that they are not locked out of their device and are able to set a new password by returning to a common factory setting. A default password can also enable engineers to readily access a device to perform diagnostics or for other legitimate reasons.
However, neither of these benefits, nor any others, are worth the dangers posed by UDPs. And there are avenues for achieving these same ends without the inherent risk of having default passwords in place – including leveraging physical access to reset devices, or other forms of multifactor authentication to reset a password. Meanwhile, for product servicing there can be dedicated support accounts that are disabled by default. When an engineer needs to access the product, the administrator will activate the support account, assign it a new, random password and set expiry time. All of these actions can be initiated by a simple press of a button after which the administrator of the product can simply read the password to the engineer who can then perform his/her tasks.
Viable alternatives for UDPs
Ending the use of UDPs should take place early in the product lifecycle during the “design” and “development” phases and, in principle, is pretty straightforward – manufacturers should not plan-out or build products that rely on shared passwords for security.[3] Which alternatives make the most sense will vary depending on the type of IoT device, each of which can have a wide range of different user interfaces and use cases that would support different authentication methods in lieu of UDPs.
Manufacturers working to eliminate UDPs can start by asking whether passwords are necessary at all for a particular product or whether alternative methods of identification would be preferable – this can include biometric elements or using a token. Other connected devices that rely on a separate trusted device – like wireless headphones that connect to your smart phone – work fine without a password as the device itself is not directly connected to the internet, and a trusted device in close proximity has to accept the pairing.
However, if a password is determined to be necessary for a particular networked device, this does not mean that it needs to have a UDP or a weak default password. A pre-installed password should be unique to a particular device, derived by a truly randomized process and with sufficient complexity to avoid being compromised. Moreover, limiting the number of permissible login attempts at one time will further help protect against brute force attacks. If users are expected to change a default-password, they can also be prompted/required to on first use to ensure this happens.
Government/external guidance on consumer IoT device passwords
- Consumer IoT Security Quick Guide: No Universal Default Passwords – IoT Security Foundation
- NIST Internal Report IR 8425 Profile of the IoT Core Baseline for Consumer IoT Products – National Institute of Standards and Technology (NIST)
- Password Administration for System Owners – UK National Cyber Security Centre (NCSC)
Signatory guidance on consumer IoT device passwords
- IoT Device Security – Cloudflare
- Passwordless Protection – Microsoft
[1] https://www.securityweek.com/over-500000-iot-devices-vulnerable-mirai-botnet
[2] https://www.netscout.com/sites/default/files/2019-02/SECR_001_EN-1901%20-%20NETSCOUT%20Threat%20Intelligence%20Report%202H%202018.pdf
[3] https://www.atlanticcouncil.org/wp-content/uploads/2022/09/AC-Security-in-the-Billions.pdf