California May Ban Terrible Default Passwords On Connected Devices (engadget.com)

According to Engadget, the California Senate has sent Governor Jerry Brown draft legislation that would require manufacturers to either have to use unique preprogrammed passwords or make you change the credentials the first time you use it. "Companies will also have to 'equip the device with a reasonable security feature or features that are appropriate to the nature and function of the device,'" reports Engadget. From the report: If Brown signs the bill into law, it will take effect at the beginning of 2020. But critics claim the wording is vague and doesn't go far enough in ensuring manufacturers don't include unsecured features. "It's like dieting, where people insist you should eat more kale, which does little to address the problem you are pigging out on potato chips," Robert Graham of Errata Security said in a blog post. "The key to dieting is not eating more but eating less." Given the huge number of connected devices available, it's also not clear how the state plans to enforce and regulate the rules.

Comments

Correct me if I'm wrong but

[Jarwulf]

aren't most of these account compromises due to stuff like an incompetent company leaving its database in plaintext or some kid phishing it from or fooling an employee somehow instead of some master hacker bruteforcing individual passwords that don't follow silly rules like having upper case and symbols?

Re: Correct me if I'm wrong but

[datavirtue]

Yes....but California is going to save the world with laws.

Good First Step

[mentil]

Now instead of a default router password, users will be prompted to change it, thus setting it to 'Password1'.
Progress!

Re:It should be

[Anonymous Coward]

all building a single OS for IoT with security built in

You think "security" is something that can be "built in." Security in software development is a mindset. How does having a secure operating system help when the web frontend developer doesn't understand how to correctly validate passwords.

updated everytime a change happens and then have this open sourced to provide greater security and code verification.

While having the source code available is helpful to see if there are security issues, that doesn't mean they will be found. Open source doesn't provide for greater security though. Open source == licensing model, not a security process.

With many software projects, open source or closed, there are often only a few people who understand the software well enough to even notice those bugs.

I don't think forcing a particular operating system down vendors throat is the solution. My idea is, everytime a vendor has a security issue on their device, I want a refund. They sold me a defective device with defective software. We need to stop calling software buggy and call it what it really is, DEFECTIVE.

Next on the agenda...

[Cornwallis]

I've also heard there are new laws in the planning that will require everyone in California be happy and rich.

Can't wait to see how those are enforced.

Have they really thought this through?

[vtcodger]

OK. I drop my toothbrush and it breaks. So I go to the store and find all six of the toothbrushes I can choose from are internet connected. I pick one, go home, plug it in. Now I enter a new password. How do I do that? It's a toothbrush.

------

My (conceptual and imaginary) grandmother buys a new "smart" TV. (Seriously, "They" apparently don't make dumb TVs any more). She plugs it in getting many of the connections right. It asks (in colloquial Latvian because it's a bit confused about where it is) for a new password. She at least has an input device-- the remote. She pushes random buttons until the weird prompt(s) go away. Congratulations grandma, you've set an unknown password and effectively bricked your new TV. Who is going to unbrick it? How?

-----

I'm not sure the world needs politicians "solving" problems nobody understands. Quite likely a case of "Now you have two Problems"

Re:Have they really thought this through?

[vtcodger]

"If the toothbrush needs to be connected to internet, there must be some way to configure it."

The issue of an internet connected toothbrush is kind of interesting. I picked it because it's a blatantly nutty idea. But Google assures me that such things do exist. How DO you configure it? The obvious notion would seem to be via a web server on port 80. But that implies that the crazy thing can get to the network -- which suggests that it either has an RJ45 network connector (who has network ports in their bathroom? Not me). Or (scarier) goes looking for a non-password protected Wi-Fi network. And even if it can get a network IP address via DHCP (What if there is no DHCP server running?) How do I find what IP address it got. UPNP? Bonjour, clairvoyance? I'd probably use arp-scan, but I think that's a bit of a stretch for a typical user. What if it has hooked up to my neighbor's Wi-Fi network?

Maybe it's got a USB port? What class of USB device does it claim to be that will allow me to get help instructions and configure the device from a terminal or browser? I wouldn't be surprised that there is such a class, but I don't know off hand what it would be.

Anyway, configuring the device likely is possible, but what's the likelihood that an average user can figure it out? Or has the the patience even if they have the brains?

So, my guess is that the devices will end up mostly running via some weird kludge with no actual security whatsoever. They'll have great passwords if that's what the law dictates, but the passwords won't be used/needed for anything.

White boxes

[The Cynical Critic]

I'm not sure this is going to cause anything other than a bunch of insecure devices disappearing off store shelves in California specifically. Don't get me wrong, this is progress, but it's not the kind of really fast progress that is actually needed seeing how really badly secured devices being sold today are going to be causing us issues decades from now.

The fundamental issue is that most IOT gear is really just really cheaply made and designed white box devices from obscure Chinese vendors consumers have never heard of and which the companies under whose name the devices are sold to consumers just order them from the vendor with their name and logos slapped on at the vendor's factory. Until you can force the white box vendors to properly secure their cheaply made and designed hardware, we're just not going to be able to make a dent in the problem.

Re:White boxes

[The Cynical Critic]

Considering how the reason why companies that use white box hardware is that said products cost them nothing or next to nothing to develop I'm not so sure they will start limiting themselves to properly secured white box hardware.

When car makers make sure all of their U.S cars are compliant with the more stringent California Air Resource Board standards they've spend billions developing them and obviously need to sell a lot of them to recoup the development costs. Companies that sell white box hardware with just their logo slapped on have no sunk capital that needs to be recouped and can easily afford to ignore California, particularly when the market for that specific product is pretty much the rest of the world.

Strict liability and products

[sjbe]

You think "security" is something that can be "built in." Security in software development is a mindset.

A mindset in a software developers head is a useless thing to an end user. It might start there but it has to actually become something more than that. Ultimately security has to manifest itself in products (software and hardware) and processes to use those products. A developer's mindset will not keep a network or device or data safe any more than and engineer thinking about how to stop a car will actually cause one to halt. So yes, security ultimately has to be built into whatever device(s) and software you are using.

My idea is, everytime a vendor has a security issue on their device, I want a refund.

Then you would have no devices because it's impossible to prove that non trivial devices and software have no security issues. Nobody could ship a product and be sure there was no security issue they missed. It is arguably reasonable however to apply strict product liability laws to software and to hold companies financially accountable for damages. Current application of product liability laws routinely provide software makers too much wiggle room to avoid responsibility for their failures, particularly with regard to security.

Re:About Time

[AvitarX]

I like easy default passwords.

I want to be able to hard reset my device and get it setup without a reference. I don't want losing the paper where I wrote it's default password to brick the device on a hard reset.

It's more challenging better to have am easy default, and force a change of password during the setup.

Penalties for negligent companies

[sjbe]

You can't "law" stupid away.

No but you can make penalties for it for companies that do stupid things. Companies are supposed to be able to hire smart people to figure this stuff out and if they fail to do that there should be consequences with teeth.

Some things you just have to let them work themselves out.

Product liability isn't one of them. Neither is negligence.

If you have a brand of devices that are constantly getting compromised. People will stop buying them.

HAHAHAHAHAHAAAA!!!! I refer you to Microsoft Windows, Adobe Flash, and Microsoft Office. Not to mention countless shitty routers and IOT devices that get pnwned every day. People buy things all the time with vast security problems that are well known about prior to purchase. Your argument is not supported by facts.

Instead, legislate fine them for security lapses

[MobyDisk]

In general, legislating one particular best practice does not fix an industry. And there are better ways than writing laws. Some ideas:

• * Require that government entities only purchase products from companies that have not had certain categories of security lapses in the last 6 months

• * Require that government entities only purchase products from companies that have a policy of fixing security bugs within X amount of time

• * Provide funding to startup a commercial product security certification organization, similar to what underwriters laboratory (UL) does for safety.

• * Setup liability law so that any owner of a device that doesn't follow industry best practices can be sued by an owner of that product.

Any of the above would mean that, for example, California government would no longer buy Western Digital hard drives. These suggestions intentionally do not state what the specific best practices is, and other than the last one they don't require laws, which are slow to change. The specific practices can be defined by some of the many organizations that already do that. Ex: OWASP top 10, static analysis, pen testing, etc. This is similar to what the FDA did with medical devices, to make manufacturers stop doing idiotic things like using unauthenticated Wifi on insulin pumps so hackers could remotely kill people.

Re:It should be

[nine-times]

How does having a secure operating system help when the web frontend developer doesn't understand how to correctly validate passwords.

Well the IoT manufacturer also has to do their job in building whatever web interface they build, but it certainly helps to start from a secure OS.

While having the source code available is helpful to see if there are security issues, that doesn't mean they will be found. Open source doesn't provide for greater security though.

Well it doesn't inherently completely make for better security. It does have some advantages, though. There's the obvious fact that there are generally more eyes on an open source project, so security problems may be more likely to be noticed. Also, frankly, security is hard to do well, and having a bunch of random developers coming up with their own solution will result in a lot of those developers doing it wrong. If you can create a coherent security standard that everyone can work from, then a lot of people have a vested interest in doing it well, and it'll probably be done well.

Obviously there are also downsides. The fact that there are a lot of eyes on the source also might make it easier for someone malicious to find an opening. Also, everyone standardizing on one security standard (or one OS) makes a monoculture. It means there's one big target to exploit, and if you can exploit it, you can get access to pretty much everything.

On the whole, I think it is smart for IoT manufacturers to use an established open source OS, both to save themselves money and to start from a point of relative security... but I think they already do that. AFAIK, a lot of those things are somehow built on Linux or a BSD. I don't think we need a singe OS, but I do think we need to figure out some security standards that establish what constitutes an acceptable level of security for an internet connected device.

I also think that, for consumer protection reasons, there should be some kind of push to open source the software computerized devices and appliances. Manufacturers can too easily stop updating things and drop support, leaving the people who owned it with no options but to replace the device.

Re:It should be

[mjwx]

all building a single OS for IoT with security built in

You think "security" is something that can be "built in." Security in software development is a mindset. How does having a secure operating system help when the web frontend developer doesn't understand how to correctly validate passwords.

Security in everything is a mindset... However a good mindset on it's own is useless. You need to give the user the tools as well.

What we have needed for years in connected home appliances is for the first configuration screen to be "Change this default password before the device becomes usable". Laws here in the UK have meant that ISP's aren't permitted to hand out devices with generic or default passwords, so every router you get has a sticker on it with your individual password.

Re:About Time

[ctilsie242]

What might be the best thing is an e-Ink display or a cheap LCD display. When the device is hard reset, the display will show a random 10-20 digit code on it, which will be the temporary password for the device. Then, once the device is logged into, it will force a password change.

Re:It should be

[omnichad]

main software developers all building a single OS for IoT with security built in

A software monoculture is great for security. Much more efficient to take down the entire globe at once when a flaw is discovered.

Re:Instead, legislate fine them for security lapse

[nickersonm]

• * Require that government entities only purchase products from companies that have not had certain categories of security lapses in the last 6 months

• * Require that government entities only purchase products from companies that have a policy of fixing security bugs within X amount of time

Stuff like this sounds great in practice, and even makes a good amount of sense - why not use capitalism itself to promote desired behavior? But these kind of restrictions on government purchasing are why government pays twice as much to make what should be easy purchases. "Approved vendors", "preferred suppliers", and "government rates" because it takes so much paperwork. This also excludes small companies who don't have staff dedicated to filling out government paperwork.

Re:It should be

[OrangeTide]

You think "security" is something that can be "built in." Security in software development is a mindset.

You mean I can't just order my embedded software from a Chinese menu and check the box for "Yes, security please" ?

My crash course in security paired down to what I could reasonably fit into a post:

The process of threat modeling is a formal analysis of the security of a system. One easy to remember process is to use the mnemonic STRIDE - Spoofing, Tampering, Repudiation (sharing of access tokens or accounts between users, man-in-the-middle, social engineering, phishing scams, etc), Information disclosure, Denial of service, Elevation of privilege.

You can begin to build a picture of your threat models with a tool like SeaMonster. That's only one example there are many other tools available of course, such as Microsoft's SDL Threat Modeling Tool.

A formal process is pretty important, even if it's as basic as a spreadsheet that lists the threats you came up with. Reviewing the list, prioritizing it, and determining a schedule for addressing threats is better than an ad hoc hand waive to developers a week before release. ("Guys, ya, um I'm going to need you to make it secure."). An iterative process for security that begins the same day you start architectural talks is the better way to approach the problem.