• aard@kyu.de
    link
    fedilink
    English
    arrow-up
    24
    ·
    1 year ago

    It’s amazing how much NFC stuff is still badly done - and how bad the response to discoveries is. I recently got a police report filed against me here in Finland for pointing out that guarding personal details of kids and parents on a phone used in daycare by an empty tag, just by the tags UID is probably a stupid idea.

    • dhork@lemmy.world
      link
      fedilink
      English
      arrow-up
      21
      ·
      1 year ago

      It doesn’t surprise me, the vendor probably thinks they’re Agile, their team delivered a Minimum Viable Product and then their Management sold it. Security was always meant to be in a future Sprint.

      If that model works for web services, it ought to work for anything, right?

      • aard@kyu.de
        link
        fedilink
        English
        arrow-up
        6
        ·
        1 year ago

        Agile, their team delivered a Minimum Viable Product

        I guess that’s kind of what got me into this mess.

        They have some shitty web application where you’re supposed to log times your kids will be in daycare. I logged in, looked around - and told the wife she can chose to log times herself, or tell daycare to do it themselves. I’m paid to deal with broken shit in my main job, I’m not doing that for free in my spare time.

        At that point I assumed the web app was some prototype their intern had thrown together for the sales pitch, and they were now desperately trying to get it functional - to my surprise I later learned that it was an older product, with quite a few customers already.

        Few weeks later wife came back upset from kindergarten over an argument about missing times - which forced me to actually deal with that dungheap, and prompted me to have a closer look at other components, like the android app they’re using on their phones as well. There’s a lot of stupid beginners mistakes in all components - not necessarily exploitable, but I also didn’t really check as in my opinion the tag thing would be sufficient to have this taken out of use.

    • r00ty@kbin.life
      link
      fedilink
      arrow-up
      12
      arrow-down
      1
      ·
      1 year ago

      Reading the article it seems they made two mistakes. The first was to make the card authoritive instead of having a account data to ensure the information matched. The second was to use a proprietary checksum algorithm instead of using an open secure signature method.

      I’d put money on the information they’re holding back being details on the checksum algorithm.

        • r00ty@kbin.life
          link
          fedilink
          arrow-up
          9
          arrow-down
          1
          ·
          1 year ago

          It wouldn’t need an account. The card can have all the data (in case it is used in an offline situation) but also have a unique serial number.

          So when an official ticket machine charges the card, it also logs the balance/tickets on the card with that ID in a central database too. Yes, it needs to be “online” within their own network. But, I’d be concerned if a large city transit didn’t have their own network already.

          Whenever it is used, provided the ticket reader has a connection it would be verified against the stored record. If the connection is offline then it uses the local stored information.

          I do wonder in a transit system like this what the advantage to an offline system is. If someone works out your “CRC32 except I xored the result with 1337” algorithm, then you’re boned and a lot of kit is “offline” and thus cannot easily be upgraded too.

    • vlad@lemmy.sdf.org
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      If there aren’t enough people that are knowledgeable enough to take advantage of something to have an impact on revenue, then you just ignore it.