California’s ban on weak default passwords isn’t going to fix IoT security

Plenty of articles have been written about the United States’s first IoT cybersecurity law due to come into force in California on January 1st, 2020.

Under the terms of the legislation (which, naturally, is available to read online), manufacturers of internet-connected devices will either have to:

· ensure that each device comes equipped with a unique preprogrammed password, or…
· require users to generate their own new means of authentication (ie choosing a password) before access is granted to the device for the first time.

This in itself is no bad thing. In recent years we’ve all seen countless reports of botnets hijacking routers, IP cameras, and other web-connected devices because of weak default passwords that ship with hardware, but are too often never changed.

The infamous Mirai malware, for instance, recruited a zombie army of IoT devices using a list of 60 common factory default usernames and passwords in 2016. Take a bow “admin/1234”, “admin/admin”, and the truly abominable “root/(none)”.

But it’s important to be clear that it’s not enough just to rid IoT devices of any hardcoded passwords being used to control access to their admin web-based user interface. Mirai scanned huge swathes of the internet, searching for open Telnet ports, and attempted to gain access to devices via Telnet by using the default passwords.

The puppetmasters of Mirai used such weakly-protected IoT devices of to launch a devastating DDoS attack against the Dyn domain name service, which in turn disrupted access to some of the world’s most popular websites.

This isn’t rocket science, and the publishing of Mirai’s code online has put such techniques into the hands of anyone moderately technical. A wave of copycat attacks, and more sophisticated botnets such as VPNFilter, in the years since have proven that an alarming proportion of IoT devices remain vulnerable.

Despite the dangers, many devices continue to use Telnet, which is vulnerable to interception and easy brute force cracking, rather than the preferred safer Secure Shell (SSH) protocol.

Legislation which demands manufacturers adopt unique passwords, rather than hardcoded defaults still too commonly-seen today, may help prevent the problem of dictionary-based attacks and hackers attempting to gain entry by using databases of common passwords – but it doesn’t mean there won’t be any IoT devices using Telnet anymore.

It also won’t address other problems such as IoT devices with weak or non-existent encryption, or internet-enabled technology which has no updating infrastructure if a vulnerability is found in the future.

Furthermore, it’s hard to picture how any legislation is ever going to stop users reusing the same password for multiple IoT devices. We see this problem rear its ugly head when it comes to website account passwords all the time, and there’s no reason to believe that users are any more careful when it comes to their routers and CCTV cameras.

A Californian law may prevent dangerous devices being sold in California if they have hardcoded default passwords. It may even have the knock-on effect of preventing manufacturers from selling their weakly-protected IoT devices in the United States.

This is undoubtedly a good thing. I would prefer that there were less devices with dumb passwords connected to the internet. It’s not that I care particularly about your device being hacked or not, but rather that I don’t want your device to be recruited into a botnet army to attack me and my computers.

What it cannot do, however, is prevent poorly-defended devices from being sold anywhere in the world. Mirai’s attack on the Dyn domain name system in 2016 originated primarily from outside the United States, on the insecure devices of those living on foreign shores, beyond the reach of US law enforcement.

If we’re going to have any hope of successfully fighting IoT insecurity then it’s a battle that needs to not just be fought in California, but in many other territories around the world.

To my mind, the Californian legislation is a step in the right direction. But we must make sure that the journey doesn’t stop just as we’ve begun. There is a long way to go before we can feel confident that IoT devices have become significantly safer.


  • By Paul Swengler - Reply

    Aloha Ghram

    TOTALLY AGREE with this!

    Never would have believed that California Politicians were smarter than Silicone Valley Engineers. Boy, was I wrong.

    Requiring usernames and passwords doesn’t work! Politicians instinctively know that and that software is now sufficiently powerful that identity doesn’t need to be static. You don’t need passwords to secure an IoT connected device. The problem is people can’t believe innovative ideas are possible if they don’t come from Google or IBM or Microsoft. That’s just nonsense.

    Grahm, simply this: BPID for IoT has a patent pending which will totally eliminate usernames and passwords to access any IoT device from MCU up. Yes, all static matching tokens in every form – are gone, completely vanished, from serial numbers to biometrics. It works and it doesn’t come from a big name. Granular security and no passwords is the touchstone of security.

    Check out the patent, it is on free patents:

    What makes this revolutionary is the embedded AI is able to scrutinize each individual, granular command, validate it, and if not valid, analyze it for its threat level, and mitigate any threat even before the command is executed.

    It works by shifting security from the perimeter to the individual instruction. That means it doesn’t work like passwords which are perimeter defenses. There are absolutely no hidden, replacement or cryptic passwords. There are no matching static tokens because they aren’t needed when security defenses are granular.

    The website is

    Let’s chat. I can explain it to you, it’s simple. And BPID is about to change IoT security.

    Thanks and aloha.


  • By Dmitry Raidman - Reply

    It is too little and too late the adversaries already shifted from default passwords to more sophisticated techniques based on software vulnerabilities of the devices. And that’s where the regulators should look very thoroughly.

    IoT companies need to embed the security in their device passively and provide clear transparency into the device Software Bill Of Material (SBOM) together with clear visibility to the protocols uses, and the nodes of the network involved to identify the poorly-defended IoT devices. These days adversaries are able to exploit known vulnerabilities or attack the software supply chain to gain access to the massive device fleets.

    The other part of it is the dynamic detection, protection, and mitigation of the persistent threats and attacks like the Mirai botnet, malware creators shifted away from the default passwords and they are quite advanced in their exploit toolkits leveraging the existence of vulnerabilities mentioned in the previous paragraph. The thing with vulnerabilities is that they are hard to control since new ones been discovered as this lines been written. Therefore an additional layer of defense is required in form of Prevention Detection and Response (PDR or EDR) solution to neutralize the threat once it gained access to the device.

    We all hope that the regulation will require the device makers to have not just complex default passwords but proper secure, firmware upgrade mechanisms, proper cyber immunity software running and protecting the devices in the field and of course processes of discovery and patching of the vulnerabilities on the devices in addition to transparency of the SBOM of the device to their users and regulatory bodies.

    This is all hard and complex to achieve taking in account that everyone rushing the products to the market from obvious competitive reasons, and cybersecurity is a complex field. This is the reason why we started Cybeats to provide easy to integrate, automated and orchestrated solution to companies building developing or operating large IoT device fleets. Contact us Today for a demo.

  • Add Comment

    Your email address will not be published. Required fields are marked *