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.

One comment

  • 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: http://www.freepatentsonline.com/y2018/0270904.html

    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 https://iot.bpidsecurity.com

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

    Thanks and aloha.

    Paul.

  • Add Comment

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