This article is part two of the IoT Security Foundations series. In this post we will introduce authentication, its pitfalls, and what makes it interesting in the Internet of Things. This article focuses on password authentication mechanisms, the most common ways they get broken, and the right measures that IoT makers can take to achieve a high level of security. There are other advanced authentication methods, that can be more secure or more efficient than password authentication under specific scenarios, but we will leave the details of those for a later article in this series.
The problem with passwords
Authentication requires users to prove who they are before being able to access a system and its resources. Passwords implement authentication of the “what you know” variety, as opposed to “what you have”, where the authentication token does not come from a user’s memory. Despite the seeming simplicity of checking a password, getting it right on the Internet of Things has not been easy. Mistakes are commonly made in deploying and configuring authentication mechanisms, by device vendors, service operators, administrators, and end users alike.
These mistakes have given rise to gargantuan botnets such as Mirai, whose sheer scale would be impossible before the Internet of Things. The original strain of the Mirai agent proliferated without the use of any advanced exploits – the infection spread by knocking on the device’s front door (a network login interface) and stating the right password. For this, Mirai was equipped with a bank of several dozen username-password combinations, some of them extremely simple, which happened to be accepted by hundreds of thousands of devices online. Those default username-password combinations were defined by the vendors, installed by the service providers across a wide set of products, and were left unchanged by either the service providers or the end users. Since password authentication, the device’s first line of defense, fell so easily, the early variants of Mirai did not need any other techniques, such as exploiting device vulnerabilities.
Why are passwords being used in embedded devices at all? Despite the inclination towards machine-to-machine communication in the Internet of Things, devices still offer shell, app, or web management interfaces. For home users, passwords are the most reasonable means to log in to those devices. By extension, passwords are used for remote administration in business environments, just because they’re simple to implement and deploy. That exposes systems to unnecessary risks, which could be avoided with stronger authentication methods, such as certificates. As long as passwords continue to be widely used for authentication, the challenge is to make them as secure as possible.
Weak default passwords are a major issue
Weak default passwords have been exploited for large-scale attacks long before Mirai. The “Internet Census 2012” project scanned IPv4 networks and tried logging in remotely with empty or default passwords like ‘root’ and ‘admin’, and was able to infect about 420,000 devices. Complacency led to multitudes of systems being exposed on the public Internet without proper authentication, including sensitive PLC equipment. To quote the project’s paper, A lot of devices and services we have seen during our research should never be connected to the public Internet at all. As a rule of thumb, if you believe that “nobody would connect that to the Internet, really nobody”, there are at least 1000 people who did. Whenever you think “that shouldn’t be on the Internet but will probably be found a few times” it’s there a few hundred thousand times.
Clearly, simple and guessable default passwords have no place on the network. We will discuss complexity in the next section. To prevent damage from default passwords, systems can ask the user to change the password on first use. Although this adds an extra step to the installation process, systems – especially those intended for business use – should take that precaution.
Complex passwords help
Administrators could prevent simple password-guessing IoT attacks by deploying devices with more complex passwords. Services like passwordgenerator.net can help generate complex, random passwords of given length, resulting in output like “eMVNgXM6KH”. Intuitively, this is a better password than “123456” – though it has downsides for a human user, who would struggle to remember it, and consequently would have to write it down somewhere.
For a formal definition of what makes a strong password, we refer to NIST guidance. SP.800-63b defines passwords as “memorized secrets”, sets a required minimum length of 8 characters and recommends allowing much greater lengths, with spaces and all Unicode characters accepted. NIST discourages many “common-sense” but unhelpful measures, such as setting expiration terms on passwords, or forcing the user to mix several character types (e.g. capital letters, numerals and special characters). NIST guidelines are built on practical research and aim to help users in picking long passphrases. Following the guidelines increases the potential for strong, user-friendly passwords that are easy to remember but hard to crack. For those interested in creating passphrases, XKCD published some popular advice, and an online passphrase generator can be found here.
Avoid reusing passwords
Because remembering a single password is easier than remembering a dozen, most users set the same password on more than one service or website. If that password gets exposed or stolen from one website, all the accounts using it are at risk of break-in. In a similar manner, device makers tend to use the same default passwords (and other credentials) across a manufacturing batch, or an entire product line. Once an attacker gets the password for one device, they can gain access to the entire batch. It’s possible to obtain a password by posing as a legitimate user, or by reverse engineering devices to extract passwords encoded in software.
To avoid password extraction in the first place, passwords should be stored as secure, salted hashes, or kept in hardware security enclaves. To prevent an extracted password from letting an attacker log in to a whole product line, makers have to use unique per-device default passwords.
Unique passwords are difficult to deploy. Manufacturers need some form of device serialization (initialization with unique data), and then some form of out of band communication to share those passwords with the legitimate users. At a minimum, devices can be equipped with printed labels showing the initial password. More advanced use cases involve enterprise-grade provisioning solutions, which take care of device initialization and user enrollment.
Attackers use password databases to check devices for commonly used or previously compromised passwords. Public services such as passwordping also use databases of compromised passwords and can help avoid choosing a password that has already been compromised. These services should only receive the password’s hash (so that the password itself is not exposed) and compare it against their set of hashes. This can help weed out passwords like “1q2w3e4r5t” that appear strong at first glance but are in fact very common and would be used by attackers. Pwned Passwords service offers a downloadable database of compromised passwords, which should be a useful tool for administrators.
Enable strong authentication for support accounts
Another kind of default passwords are those used for service provider support accounts. A typical home router, provided by the ISP, has a remote management interface to let support personnel reconfigure the device in case of need. If the network interface is protected with a simple, widely shared, or easily guessable password, the device is at risk of takeover by internet attackers. Vendors should employ strong authentication on any support accounts left on the device, especially if they are not visible to the user. Where possible, support accounts should be removed outright.
Prevent brute-force access
Even unique and fairly strong passwords can be cracked by brute-force attacks. If a system allows numerous password guessing attempts without imposing slowdown or another penalty, an attacker can repeatedly try increasingly complex password until they find a match. Devices should detect repeated authentication attempts, increasingly delay their responses to make the attack inefficient, and alert the user whose account is under attack, for example by email. Devices that have graphical interfaces can use CAPTCHA. Some administrators lock out the user account in question after a number of failed logins, but that may cause denial of service, and should be used with caution if at all. Failed login attempts should be logged and reported, as should successful ones – it’s generally a good idea to let the users view the last activity on their accounts and devices. In case of unexpected activity resulting from compromise, users should be able to reset their passwords and recover their accounts.
Unique usernames are important
Default user names help credential-guessing attackers almost as much as default passwords. Users should create accounts with unique usernames, and even administrative accounts should be able to change user names from ‘root’ or ‘admin’. Authentication systems should avoid meaningful error messages when a login attempt occurs on a non-existent username, instead reporting the same error as if the username existed but the password was wrong. This protects against attackers enumerating the active accounts on the system.
Rethink password recovery processes
Finally, password recovery flows can quickly become the weakest link that leads to account compromise. Security questions that allow for password reset or recovery are a bad idea, since the answers are often easier to guess (or look up) than the passwords themselves. Instead of security questions, it is better to use randomly generated recovery codes instead. Whenever the user requests a password reset, avoid sending the new password to their mailbox; instead, send a link with a unique one-time token, which takes them to the password change screen. A token in a link can hold much more entropy than a password of reasonable length, and it’s easier to click a link than to copy and paste a password.
Conclusion
Passwords have their place in the Internet of Things and are likely to remain in wide use in the foreseeable future. We have examined some of the ways that password authentication gets compromised, and outlined the measures needed to securely deploy it. Automated scanning products like those offered by VDOO can help determine if proper security measures have been taken in configuring a product, but it is important for the end users, owners, and operators of the devices to be aware of the issues and demand proper solutions. Only then will IoT vendors become responsible for secure configuration and operation of their devices.
VDOO 