Genuinely curious how people still manage to fuck up this kind of super basic secure coding practices
IoT is electronics people coming into the software world and building software like it's the 90s.
Not in my experience. But it's obviously not the same everywhere.
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.
you'd be surprised to learn how many pieces of code were designed, written and shipped by one man army.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.