Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

10/13/2016
10:30 AM
Daniel Riedel
Daniel Riedel
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail vvv
100%
0%

IoT Default Passwords: Just Don't Do It

The rise of the Internet of Things makes the use of default passwords especially perilous. There are better options.

Earlier this month, an underground forum released the code for the Mirai malware, which lets attackers hijack the thousands (and counting) of Internet of Things devices that are used to carry out distributed denial-of-service attacks.

Panic ensued.

Of course it did. This hack means that everyone can now view the code that allowed someone using the name Anna-senpai to harness 380,000 bots via weak telnet connections. Let's ignore for now that in 2016 there is absolutely no reason to have telnet on any IoT device.

That aside, much of the subsequent hand-wringing over default password damage control missed the one glaring thing that manufacturers, startups, and providers can do to prevent this sort of devastating vulnerability: Don't use default usernames and passwords in the first place.

The most common reasons for using default usernames and passwords boil down into a few key arguments (when you leave out "we've always done it this way," which I won't even dignify with a response because I know if you're reading this, that's not an argument you care about).

Users should reset the username and password when they get a device. Philosophically, they should. In reality, do they? No, they don't. This is putting your device security into the hands of human nature, which runs directly counter to high security by always looking for the path of least resistance.

It costs more. Let's be real: It probably will cost more up front. But the more important question is whether that investment is worth preventing a likely future debilitating attack on your network, your company, your customers, and your brand. Cyberattackers are becoming more sophisticated by the second, and as the Dark Reading audience knows, we've passed the time for "if" and moved into "when" as it relates to being attacked. It's a common argument for any cybersecurity investment, but it bears repeating because so many organizations will want their team to stick with the username/password formula.

It takes more time. Again, that's true. But the good news is that the technology exists today to make default passwords on IoT devices obsolete. It's not even a herculean undertaking; your engineers could implement the fixes below in a matter of weeks:

  • Fix 1: Tie device security to a globally unique identifier, or key that would be a different code for each device ensuring that someone can’t guess the password for the device. This isn't ideal, but it's miles better than the admin/password approach.
  • Fix 2: Generate a one-time password that a user is forced to reset as part of setting up a device. If there is a reliance on the user anyway to reset a password, at least make it mandatory.
  • Fix 3: Create a shared certificate that is used with the device that needs to pair with the IoT device in question, perhaps using the "trust on first use" principle (which locks the device to the network or application upon first use) or Apple/Android's authentication platform. Similar approaches could be devised through OAuth, public key infrastructure, or other key exchanges, which give the ability to create a handshake upon installing the device.
  • Fix 4 (and the best, in my opinion): We build an industry standard for IoT authentication that is tested by the best minds in the world in infrastructure, security, and manufacturing. As IEEE points out, several of its standards address security elements that are applicable to IoT devices. These include IEEE P1363, a standard for public key cryptography; IEEE P1619, which addresses encryption of data on fixed and removable storage devices; IEEE P2600, a standard that addresses the security of printers, copiers, and similar devices; and IEEE 802.1AE and IEEE 802.1X, which address Media Access Control Security (MACsec).

Linksys has at least made headway with its WPA2 passwords being unique on each device. So the market is learning, but not fast enough.

The bottom line is that IoT isn't going anywhere. We'll soon live in a world with billions of devices that will do everything from watch your cat to measure your REM sleep. With a little effort, your organization can be at the forefront of protecting these devices, all while breaking the seemingly endless cycle of username and password vulnerability.

Related Content:

Daniel Riedel is the CEO of New Context, a systems architecture firm founded to optimize, secure, and scale enterprises. New Context provides systems automation, cloud orchestration, and data assurance through software solutions and consulting. Daniel has experience in ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
97% of Americans Can't Ace a Basic Security Test
Steve Zurier, Contributing Writer,  5/20/2019
TeamViewer Admits Breach from 2016
Dark Reading Staff 5/20/2019
How a Manufacturing Firm Recovered from a Devastating Ransomware Attack
Kelly Jackson Higgins, Executive Editor at Dark Reading,  5/20/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-7201
PUBLISHED: 2019-05-22
CSV Injection was discovered in ProjectSend before r1053, affecting victims who import the data into Microsoft Excel.
CVE-2018-7803
PUBLISHED: 2019-05-22
A CWE-754 Improper Check for Unusual or Exceptional Conditions vulnerability exists in Triconex TriStation Emulator V1.2.0, which could cause the emulator to crash when sending a specially crafted packet. The emulator is used infrequently for application logic testing. It is susceptible to an attack...
CVE-2018-7844
PUBLISHED: 2019-05-22
A CWE-200: Information Exposure vulnerability exists in all versions of the Modicon M580, Modicon M340, Modicon Quantum, and Modicon Premium which could cause the disclosure of SNMP information when reading memory blocks from the controller over Modbus.
CVE-2018-7853
PUBLISHED: 2019-05-22
A CWE-248: Uncaught Exception vulnerability exists in all versions of the Modicon M580, Modicon M340, Modicon Quantum, and Modicon Premium which could cause denial of service when reading invalid physical memory blocks in the controller over Modbus
CVE-2018-7854
PUBLISHED: 2019-05-22
A CWE-248 Uncaught Exception vulnerability exists in all versions of the Modicon M580, Modicon M340, Modicon Quantum, and Modicon Premium which could cause a denial of Service when sending invalid debug parameters to the controller over Modbus.