to Modicon 984 Industrial Controllers (1991 vintage), modern stuff, and everything in between is either horrifying or funny depending on your point of view.
I was pondering this during the seminar. There is a useful initialism here..
N3 [—] Nice but Not Necessary
Usually, this is financial, but security works too. As a hacker, what fun things can I do with your IoT device?
[ol]
[li]I can take control of it and use it for DDoS attacks and brute force hacking.[/li]
[li]For my spambot, I need the high speed connection noted above, and I need memory for my email list. [/li]
[li]Your machine is where I want to store my kiddyporn collection.[/li]
[li]I can take control of whatever your IoT device is attached to [—] your kitchen stove, your methyl isocyanate system? Fun? Wow![/li]
[/ol]
Okay, I need an IoT device to monitor some condition in my factory. My device reads some sensors, and emails a report each hour, to me that I can read on a computer or on my cellphone. Maybe I will log the measurements on the device. Once a week or month, I access the device and transfer the log to a USB[ ]stick. If I am monitoring the system with a cellphone, I can call the factory and tell someone to take a look at it.
I doubt there is a cost advantage to 300[ ]baud over what ethernet does, but it is fast enough for my application, and all sorts of nasty activities require speed. A couple of megabytes are sufficient for my log files, and not sufficient for a spam database, or for even one digital photo. Is it a good idea for me to take remote control of factory equipment from my cellphone at my cottage? A guy standing next to it has a much better idea of what is going on.
I am happy figuring out IOT security is mostly not my problem mostly.
My main concern is that automation performs the intended function.
For your bullets, if the troublemakers were rational I agree, most IOT would not be at risk. However as some find creating havoc fun even when it is relatively pointless, I chose to leave the network interface on my gas fired water heater (honeywell) and my dishwasher(GE) unplugged.
Fred
There are so many logical ways as compared to encryption to provide enough security to your motley IoT crews.
As pointed out you could just slow the interface down to a crawl. You need to see the temperature? 10 baud aught to do it. Any self respecting hacker would commit suicide rather than hack through 10 baud. It just ain't worth it.
Login attempts. Miss one wait 10 seconds. Miss two wait 30 seconds. Miss three wait 10 minutes. That will blow them into the weeds after about five minutes of agony.
Hacker after dealing with either of these simple road blocks:
The delays thing is insanely devious if your staff knows of it and it's not made public in any way. You make the entire response the same as just a failed password. The attacker can actually somehow use the correct password during a blackout and simply get a "bad password" response with the correct password. That makes the entire thing non-determinate and they'll never try the correct one again since it has already failed. It's sweet.
In practice it's better to use a cryptographically enforced delay, via a "password hashing function". The advantage of this is that even when the entire database of stored hashes is leaked (as it can be) an attacker can't just bypass the delay. Whereas with a software-based delay system they can, and have done so historically.
Before allowing a user to set a value as a password, check it is long enough and not in a list of already-breached passwords. The Have I Been Pwned list is a good one, v6 has 573 million passwords.
If it's long enough and not re-used from a breach, use a "password hashing function" (not to be confused with a cryptographic hash function) like Argon2id or PufferFish to store the password. A "Password hashing function" takes (at least) three inputs: the password, a unique per user "salt" value, and a difficulty factor. The difficulty factor should be tuned to take at least 10ms on the lowest-end supported device that will be storing the result (might be a server for an internet-connected account, might be someone's phone for a local app). The output of a "password hashing function" is a structure containing the result of the calculation, the "salt" value, and the difficulty factor. It's computationally impossible to reverse the result to get the password any faster than just trying possible passwords and checking if they're equal. Since that takes at least 10ms, and the users can't re-use breached passwords or too-short passwords, attackers are slowed enough that it'll take many years even for most low-entropy passwords.
Somewhat surprisingly, yes. There are a few key points as to why this is secure:
[ol 1]
[li]Per-account salt values mean that an attacker can't simply compute hashes for all possible accounts at once, but has to repeat their brute-force attack for every account in turn.[/li]
[li]Minimum length requirements mean that the space of potential passwords will be large enough that attacking any given user will take substantial time. EG 10 character minimum with the 95 US ASCII printable characters found on keyboards allowed means (2^(10*log2(95)-1)*10ms)=3E17s ~= 9.5 billion years on average to brute-force if the password was chosen at random.[/li]
[li]Disallowing breached passwords means basic dictionary attacks fail, and brute-force becomes required. While many users will still pick bad passwords (so the entropy calculation above will be an overestimate) it will still take months.[/li]
[/ol]
You can use larger values, but the bigger the delay the more load on your server, and the more likely it is for a user to notice. You generally want user processing to be under 16ms (1 frame at 60FPS) for any action, definitely under 64ms (4 frames, noticeable to most people). Otherwise your system will feel slow. Since weak passwords are disallowed by the first rule (following NIST's minimum length requirements and excluding breached passwords) the work an attacker will need to expend to get into any account will tend to be quite long. If you're protecting particularly valuable data (bank, email, etc) use a larger delay and asynchronously show the user a status page. Client-side pre-processing is also possible to allow for a higher work factor without overloading the server.
And of course you can also add "feel good" security like an increasing lockout time on failed login attempts, but the basic security model of assuming that the attacker knows all data except explicit secret keys/passwords doesn't depend on that. Basically, assume your password database will get leaked and the attacker can try out passwords as fast as their hardware will let them, and rely on the hardness properties of the password hashing function to limit that rate.
Have you got a link to this type of security? You've described it pretty well but if I go to implement it on my next embedded device I'll probably go off the rails somewhere without a road map.
Why have remote logins on an IoT device at all? In my example above, the machine sends out emails. There is no need to read emails. Remote access is a security hazard.
Remote logins requires trained, disciplined users. What if a user uses their strong password at some other site that gets hacked?
I was vacationing a couple of weeks ago. I have an idiot neighbor who pesters me all the time. When he found out I was out of town, he called to tell me he was standing in my back yard. I guess he thought that was funny because he was drunk. I have pretty comprehensive home security with lots of cameras. I think he didn't believe they are real. It took me about 4 minutes using my cell phone to send him a capture of him standing in my back yard. He knows those cameras are real now.
Takeaways-
1- I kinda like the internet
2- I don't have internet connections to my garage doors or water heater.
3- My neighbor is an idiot.
Brad Waybright
The more you know, the more you know you don't know.
my security cameras on the holiday farm get used more for grass length monitoring and checking the weather than anything else. Err I do have internet connection to my water heater so i can have a shower before going to bed when we get there.
I think my response would be "yep your a right tit"
![[rofl]](/data/assets/smilies/rofl.gif "[rofl] [rofl]")