IoT devices are generally built and programmed by electronic engineers. They have no knowledge about software security and neither do they care.

While true in many cases, in my experience it's not only the engineers. Unless you have the senior managers on board as well, they'll just lean on the engineers to "ship now".

And those managers don't care either because their area is in electronics not software.

IoT is electronics people coming into the software world and building software like it's the 90s.

While EEs are part to blame, the other half is just graduated (or "bootcamp graduated" - let's put it this way) developers that know all the node.js shortcuts but don't know about the fundamentals of internet security.

Not sure we can blame bootcamps - I learned nothing about internet security in my software engineering college course.

But you probably knew that is was something to consider. And weren't told that you are basically a full fledged developer after a 3 month web dev course and after reading "cracking the coding interview". The Dunning–Kruger effect is heavily at work there.

I'm not the person you responded to, but not really. My college courses - admittedly as a Computer Science major, not Software Engineering - were laughably lacking any practical education. The closest we had was one group project, and we didn't even learn about things like version control.

Security? Forget it.

I've never gone to a bootcamp, but I'd wager that they at least mention security in their classes. College was the equivalent of the PHP documentation that had incredibly insecure examples that people "learned" from.

That’s wrong. An engineer has a couple managers above. Product, project, platform manager. You name it. Engineer is just another blue collar worker nowadays. No decision making power. I was not allowed to save company $40k, they told that numbers shouldn’t interest me. If management says, we need no encryption and authentifition, it’s totally ok. I just print their emails with this statement for later.

Engineering is absolutely not blue collar, but this has nothing to do with the issue you’re facing. If you found an opportunity to save $40k and they said you shouldn’t care about numbers, then either you have poor management or there’s more to the story that you didn’t share. At the very least competent management should have been able to explain why saving the $40k was the wrong trade off.

Yes, competent management. Didn’t experienced much companies having it. With competent management I could save my salary for couple years in this project alone. The client ist other branch of the same company. I could design a pcb with components for our needs, instead of that management wants to go with expensive 3rd party module having all bells and whistles on it.

Edit: pcb design is risky. But the system is very primitive having voltage regulator and single integrated circuit in it. I doubt this department with current performance would survive as independent company.

If you can save 40k and they don't care. Ask for a 40k raise and if they say they don't have the money ... well ... you know where to get it.

Managers get their cues from engineers. Electronics companies obviously mostly have electronics engineers and they run the engineering side.

> Product, project, platform manager

you'd be surprised to learn how many pieces of code were designed, written and shipped by one man army.

They are generally designed by electronic engineers and programmed by programmers. And most programmers don't care about security all that much.

> and programmed by programmers

Not in my experience. But it's obviously not the same everywhere.

Maybe in garage projects, but there it can as well be in the opposite way. Would be really surprised to see it mixed in a corporate setup or with even smaller design contractors.

As an electronics engineer with a decent grasp on software as well... that hurts ;(

Out of interest what strategies could be implemented to avoid this?

I've worked as a developer for a number of companies who handle sensitive data and I could have fairly easily have pushed malicious code. Even with mandatory code reviews, significantly complicated code with a well placed security hole would likely be missed.

I work on encrypting movies for distribution, so there's a spectrum of attacks we try to consider.

1. Beginner opening Firebug / Devtools - use UUIDs for all the things, don't make anything guessable. Scrypt/bcrypt passwords on a separate Oauth system for all passwords / logins, manage all sessions with access tokens that are checked on each operation, allow immediate revocation of all open sessions.

2. Novice / Amateur attacks on the API or backend - make sure as much security as possible is in global middleware on the application, on by default, opt-out explicit. Long random access tokens, use either DB checks or constant time comparison to verify, do rounds of self and third party testing to make sure there's no cross privileges or escalation.

3. Protect against ourselves going rogue / being compromised - all keys in a HSM, the HSM also has the list of certificate chains it will trust, only modifiable by N of M keycards held by top execs, assume compromise at every stage and design the systems to mitigate impact. Ideally design so catastrophic attacks are impossible without collusion among top level company execs, and all other attacks, even when successful are downgraded to inconveniences, preferably minor.

> 1. Beginner opening Firebug / Devtools - use UUIDs for all the things, don't make anything guessable.

Is that actually necessary/useful?

> Scrypt/bcrypt passwords on a separate Oauth system for all passwords / logins, manage all sessions with access tokens that are checked on each operation, allow immediate revocation of all open sessions.

why Oauth instead of just a regular user table, login POST form, and the rest as you describe?

Not disagreeing, btw. just curious.

In this case oAuth is more because we have multiple products, might have done without it for just one, but it somehow seems to make more sense to have a separate system with isolated human data anyway, what with GDPR and all. The actual application has only the user UUIDs, can null or pseudoanonymise the references as necessary. This is B2B so slightly different rules apply for auditing etc.

And yeah, obscurity is not security but is useful in itself. Smaller attack vector (can’t leak info by iteration) less competitive info leakage (you’ll never figure out how many customers we have unless we tell you). Also has advantages with regards to database replication, backup restore and sequence management, but that’s another topic.

Not my post but my answers would be:

> Is that actually necessary/useful?

Yes, removes guessing, incremental attacks and off by 1 errors/attacks. Obfuscation is bad encryption but good policy.

> why Oauth instead of just a regular user table, login POST form, and the rest as you describe?

Sessions are fixed and can last an indefinite amount of time as an example.

But [token based system X for client/server or some kerberos variant for semi-trusted or m2m] will fill this void as well.

They should have paid for code audits, penetration testing, and the whole nine yards before putting anything in a customer's hand. The whole point of this company is based around a physical security device with online controls, to not do any of that is a downright folly in my opinion.

Maybe they took the „f*ck it, ship it“ advice too seriously and shipped it a bit too fast?

Who knows but after learning this I would be highly cautious to buy anything from this company until they‘ve proofen to be more careful in the future.

I am fairly certain that the lean methodology of "if you are not embarrassed by your first release, you released too late" may have been a factor.

Being a Kickstarter project, the pressure to meet production deadlines is severe, and any technical debt inherent since the 'quick and dirty' MVP probably stays unpaid.

Lack of experience?

Silicon Valley prefers teams to have epic backstories, not experience.

A first-year dropout from MIT and a Thiel fellow are much more likely to get funded than an engineer with a state uni BSc+25 years industry experience plus a former sales manager in the same industry.

I'm just guessing, but I think experience would actually get you more investment. But interesting backstory gets you more press. Thus the impression that backstory is more important. Most funded startup founders are older and experienced. They just don't get as much tech press coverage.

Kind of like why many people fear sending their kids to school because they might be killed by a mass shooter. When in reality, the drive to school is much more dangerous.

This company is from Canada, not Silicon Valley, and has nothing to do with MIT or the Thiel fellowship. Please avoid polluting comment threads with this kind of off-topic sneering.

If they had inexperienced developers, that's most likely because they're cheaper, not because they have an amazing narrative behind their backs.

Aka the "Nerd Rockstar Bias"

who is "Silicon Valley"?