HaJ3FgupAm8RrDJW3MHgT9X7Ft27eVaD
you are viewing a single comment's thread
view the rest of the comments
[–] 2 points 1 week ago* (7 children)

Quick question: what would be the correct way to handle this, security wise? How should they acquire their token if it isn't present on-device?

I mean, each device could have its own token, but you could still sniff it, maybe? I dunno.

How should Flock have gone about this if working to their own self-interest?

  • source
  • hideshow 7 child comments
  • [–] 15 points 1 week ago (2 children)

    Ethically? Expire the token since it's compromised, and offer to refurbish all units in the field since flock screwed up, a now all customer data could be poisoned/suspect now.

    Realistically? Keep going like nothing happened an make it a customer support problem while pushing new hardened cameras that cost more. Because the product alone loudly flags Flock as a bunch of amoral greedy fuckwits.

    I won't suggest ways to actually make their product bulletproof because I care and we don't need to make this problem worse for everyone. It is a tantilizing problem space but there are never any perfect answers in security, only relatively better/worse ones.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 6 points 1 week ago (1 child)

    Oh, I don't mean afterwards. I meant before it even happened.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 1 week ago

    You give each camera its own token, and validate it with hardware ID.

    Even better, give them hardware token, that can sign, but does not leak its keys.

    In either way, you can ID the device, and block unsold and confirmed stolen/damaged ones. And never accept traffic from anything else.

  • source
  • parent
  • [–] [S] 11 points 1 week ago*

    One way would be to generate a unique private key on the secure element / TPM and its public key stored on the server for validation. Each API request would need to be signed with a relatively short expiration time. That way the code never contains sensitive content such as an API key, an exploited device only holds in RAM a signed certificate that is valid for a short period of time, and the certificate can be revoked/blocklisted on the server if compromised.

  • source
  • parent
  • [–] 1 point 1 week ago (2 children)

    y'all just givin the work away huh? don't answer this unless you are getting paid.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 1 week ago (1 child)

    O... Kay, I'm just trying to expand my knowledge about this particular case. I'm mostly a web dev but I'm trying to expand into security a little bit as well because I think that's important for my field. It just wasn't a part of my curriculum at uni 10–20 years ago.

  • source
  • parent
  • hideshow 1 child comment