aeronautic

Agree.

While I love rust and think it (should) replace C for web servers and the like, the majority of the issues with IOT devices are just basic security oversights and design errors.

You raise some very good points:

1. Secure by default should be mandatory. MS learned that one the hard way.

2. Consumer protection laws would certainly get device builders attention. I think that is required. But I doubt the current administration is included to enact such laws.

It is a shame that devices are certified by UL and FCC, but there is no security certification or even a basic audit that would catch: security backdoors, default / blank passwords, auth over http, basic XSS and CSRF vulnerabilities etc.

The bad news is that we don't know how to design a device with Linux and internet services that will be secure without updates for 5-10 years. So we either insist on updating .... or we keep some of the darn devices off the internet.

At at minimum, we should insist on having devices that don't listen on ports just waiting to be hacked. Devices should only connect out.

Very good point. Even requiring the user to specify a maintenance window can ruin the experience.

Some patches should be able to be made "hot", but that takes extra ram which is often squeezed to a premium in a device.

I would recommend:

- We not put devices on the internet that do not have a core, hard requirement to be on the internet. This rules out toothbrushes, toilets, pillows etc.

- Devices do not open listening ports and only connect out. This eliminates a whole class of shodan visible attacks.

- Devices give users some option of when an update is required and when the user can apply it. If the device can be managed via a HomeKit or Phone UI - these options can be made pretty usable. Alternatively a yellow light on the front of the device if suitable to indicate an update is available.

Regardless, the current path of listening devices on the internet and not being patched is untenable.

Still true when I tested last year. The core protocol does not have a defined way to get the browser to forget the login.

You have to resort to different fudges on different browser.

Net/Net: the http auth ui sucks, has bad usability, weak crypto, and is not robust with logout.

HTML/form based auth can be made robust and is a preferable alternative in every case.

True point. The difference is that enterprise apps understand the need to patch and update. IOT devices and device builders largely do not.

IOT devices today look pretty much like any other internet device too. Linux, good CPU horsepower, ample memory and internet connection. More than a few exploits that work on enterprise servers can be adapted for IOT devices.

Add to this a lack of awareness of basic security issues among device builders and you've got a problem. That is why we are seeing so many security issues with IOT devices.

Love it.

I know! Why do device manufacturers need to be pushed for this? We consumers keep buying stuff that has been put on the internet with little to no thought about security today or tomorrow.

IOT will get much worse before it gets better. I say this from working with device builders for 2 decades. The level of attention to security is sadly lacking.

If the device does not listen, i.e. it calls out, then it is inherently much more secure. However, many devices use an embedded web server and do listen for requests.

If the device does not listen, and polls regularly for updates, then that is fine ... perhaps even ideal.

Do you mean basic & digest http auth built into the browsers? If so, yes, they are bad. The issue is you cannot reliably implement log off on all browsers.

I know, it is a very sad state of affairs.

In doing IOT for 2 decades, this is probably one of the biggest issues. At best, most devices have a "download firmware" option that 99% of users can't operate.

I could go on about dozens of other issues, like back-door field-service passwords, http not https, passwords in the clear, endless XSS vulnerabilities, but this is one of the biggest.

Thanks everyone for some great comments and discussion. Really appreciate your time and feedback on the article.

I'll fold in the feedback and the ideas and go forward with it.

Thanks all

OP: Michael O'Brien

No argument on that (except the horseshit ;-)

Coding is easy, writing is just darn hard!!

Thanks for the ideas. I'll check those out.

Sorry that is not quite what was intended. I've revised the text to say:

If your database supports low cost encryption at rest (like AWS Aurora), then enable that to secure data on disk. Make sure all backups are stored encrypted as well.

i.e. this kind of encryption costs very, very little and give you physical security if you need it.

I agree with you, but I understand his wish though.

Security sometimes is just hard and it is unrealistic to hope that all developers, everywhere, all the time will get it right.

The more the platform can do, the better.

As the author, I should clarify that I am a developer - full time and have been for years. If my english seems to imply a lack of depth of understanding - I'm sorry.

The purpose of the checklist is to get people thinking about items they may have forgotten to address during their dev. In the push to ship new products quickly, that happens all too often.

I agree with you that there are many more important and basic things to do first when securing your app - than worrying about APTs. I did not think the checklist gave that impression?

Try this to get you started:

https://www.troyhunt.com/understanding-csp-the-video-tutoria...

Thanks for your well structured comments.

The purpose of the checklist was to get people to think. It is really hard to do much more without going very long.

A number of people have suggested that I link implementation background off each item. I think that can work and layer the info as well.

I think we can all agree that developers can get better educated about security and can participate building security into the product from the very start. It is hard to engineer security in via a sec-team at a later stage. Education is the key.

That is right. The key point is to reduce exposure to SQL injection by not formatting queries. Prepared statements help solve a whole class of bugs at a lower level.

I'd recommend you start with the items at the very end of the check list. Make a list of the threats and plan who you need to defend against.

That will then allow you to cull the list down.

I'm not sure I fully understand what you are saying. Can you elaborate.

Nicely said.

The one mod I'd suggest is:

If someone has gained access to the passwords and has not used the password yet or was not interesting in directly using the password themselves, but rather, they on sold it. There is a window of opportunity that rotation helps.

For example: you may be on one of the password lists being sold in the dark web. The owner of the list isn't hacking you, but those purchasing the list will some time soon.

So more specifically, you could be compromised by malware on a PC holding the password and that password may be extracted, sold and may not be used against you for months. Rotation helps in this case which is more common than we care to admit.

Sorry, I should be clearer (late here).

With time passing, the chance of you or anyone with access to the password being socially engineered, or some other human error, or a hack on your PC desktop systems, increases linearly with time. The password may last a decade of brute force cracking, but we humans .... continue to make mistakes far more frequently.

So rotating passwords protects against the accumulation of human mistakes and insider threats.

If you are using proper hashing, then your passwords should be safe even if the hashes are compromised.

Could you please point to the NIST recommendation you mention. I thought they said that you should NOT force customers to change passwords. But that is different to you rotating your own critical passwords at a time of your choosing and on your policy.

No, we don't encrypt indiscriminately. We selectively pick fields to encrypt - fields that are highly sensitive.

And you are right, we do this because an ops error can easily make a mistake sometime in the future and probably will one day. We all make mistakes and defense in depth is all about that.

Are you sure the objects remain leaked when a connection disconnect comes through? I don't have hard data on that.

Depending on the node web framework (express, ...) they may handle that differently and may have timeouts to cleanup.

I'd love to get a firm answer on this one.

Both. You want to choose a good password and then not let it get too stale. A very old password (say 1 year) has a higher chance of being subverted purely because there is more elapsed time wherein attackers could have gained access.

Choose good passwords, long, special chars, preferably random and generated by a password generator / manager. And then change periodically. That period depends on your application.

We change our cloud passwords and keys every 90 days.

Yes, we're not protecting against the app being attacked, the key being jacked and then the attacker getting access to the db. Rather, we're protecting the database against being accessed directly. That could happen due to an error in configuring network access to the database or another service could be compromised that has access to the same database -- as has happened to many mongo databases over this year.

Password hashes are handled separately using bcrypt - another story.

For the User.email field, we crypt/decrypt in the ORM/DB layer. So we search with the encrypted value that is stored in the db. App code provides plain-text email, ORM encrypts and searches with that value. Symmetric encryption of short strings is pretty fast and this is not a high volume API.

We use rate limiting on the API to protect against DOS on this API.