Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

1. Thats ok. If you’re expecting your rfid tokens not to be copied just because it seems inconvenient to do so, you’re in for a surprise! Your ticketing system cannot assume tickets in any form cannot be replicated- they can be and if you introduce such a vulnerability in your system, you will lose revenue

2. As per 1, no issue

3. That’d be a great feature if true, I’m all for immutability. However , qr codes can be defaced easily, hopefully the built in checksum defend against that. a more likely threat your system needs to defend against is that new qr codes can be generated extremely quickly

4. Both systems are the same speed, both systems require accurate targeting by the user, an rfid token slightly askew of the reader will not read since it won’t be able to influence / absorb the generated rf - most of these systems work by providing power to the rfid token and it communicates back not by transmitting its own signal but by exerting influence on the signal it’s receiving. It’s a very very low power interaction and very sensitive to positioning

A better problem than 4 is that you entail staff overheads with a visual system to keep them clean.

Read / write is a bad feature, you will lose ticket sales.

Recycling these is not practical. Direct reuse risks jamming the vending machine (used tickets end up subtly bent, very hard to reliably deal with), actual recycling isn’t viable, the energy required and emissions produced exceed that of creation of a new card from raw materials.



> Your ticketing system cannot assume tickets in any form cannot be replicated- they can be and if you introduce such a vulnerability in your system, you will lose revenue

Yes, the question is not whether such system would be abused, but how much. But this is in the end what businesses care about.

Will QR codes be abused more than NFC chips? Likely yes.

Will it produce a larger financial loss than the cost of the NFC chips?

Can I mitigate these losses by a centralized validation system (each terminal needs a network connection with low latency guarantees)? Sure, but how much will it cost?


A centralized system is how tags work already, so you can't toss your ticket to your friend behind you and have them reuse it.


These NFC chips have counters to deactivate themselves after the allocated number of trips has been reached.


40 years ago we had a read-write system based on mechanical trimming of a piece of card and a physical time stamp[1]. It's absolutely possible to roll out a system to keep track of journeys that doesn't require fancy embedded ICs.

[1] https://www.facebook.com/uktvads/videos/kerching-a-saverstri...


NFC tickets have "antipassback" features, eg, stores the last tap so you can't "toss your ticket to your friend behind you".


1. NFC tickets with embedded security are robust against replication, at least to the extent required for transit.

On 4, QRs are substantially slower to be read and decoded. NFC/RFID have a range of ~100mm and the field shape is dependent on the antenna design, however it is way more tolerant than QR using IR/laser. As for "entail staff overheads", we are talking about systems that process thousands of taps/day through single gates. Anything that reduces maintenance requirements is absolutely a priority.

As for "read/write is a bad feature", I don't really understand your point.

Ultralite RFID/NFC tickets are routinely recycled where they are used to replace old magnetic systems that have belt transports for the magnetic tickets. The read/write heads of the magnetic stripe are replaced with NFC readers but the belt transport and capture mechanisms remain.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: