5 ms·

Genuinely curious how people still manage to fuck up this kind of super basic secure coding practices

rkh2018 8y ago
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.
- cyberferret 8y ago
  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.
kypro 8y ago
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.
- bojo 8y ago
  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.
- sudhirj 8y ago
  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.
  - mercer 8y ago
    > 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.
    - consp 8y ago
      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.
    - sudhirj 8y ago
      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.
petethepig 8y ago
Lack of experience?
rapsey 8y ago
IoT devices are generally built and programmed by electronic engineers. They have no knowledge about software security and neither do they care.
- user5454 8y ago
  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".
  - rapsey 8y ago
    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.
- varjag 8y ago
  They are generally designed by electronic engineers and programmed by programmers. And most programmers don't care about security all that much.
  - rapsey 8y ago
    > and programmed by programmers Not in my experience. But it's obviously not the same everywhere.
    - varjag 8y ago
      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.
- raverbashing 8y ago
  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.
nikanj 8y ago
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.
- throwawayqdhd 8y ago
  Aka the "Nerd Rockstar Bias"
- emblaegh 8y ago
  If they had inexperienced developers, that's most likely because they're cheaper, not because they have an amazing narrative behind their backs.
- jjeaff 8y ago
  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.
- acchow 8y ago
  who is "Silicon Valley"?
- tomhoward 8y ago
  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.

rkh2018 8y ago

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.

cyberferret 8y ago
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.

kypro 8y ago

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.

bojo 8y ago
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.
sudhirj 8y ago
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.
- mercer 8y ago
  > 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.
  - consp 8y ago
    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.
  - sudhirj 8y ago
    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.

petethepig 8y ago

Lack of experience?

rapsey 8y ago

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

user5454 8y ago
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".
- rapsey 8y ago
  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.
varjag 8y ago
They are generally designed by electronic engineers and programmed by programmers. And most programmers don't care about security all that much.
- rapsey 8y ago
  > and programmed by programmers Not in my experience. But it's obviously not the same everywhere.
  - varjag 8y ago
    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.
raverbashing 8y ago
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.

nikanj 8y ago

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.

throwawayqdhd 8y ago
Aka the "Nerd Rockstar Bias"
emblaegh 8y ago
If they had inexperienced developers, that's most likely because they're cheaper, not because they have an amazing narrative behind their backs.
jjeaff 8y ago
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.
acchow 8y ago
who is "Silicon Valley"?
tomhoward 8y ago
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.