UID vs alternative ID (barcode) and how readers work

Forum / MIFARE general topics and applications / UID vs alternative ID (barcode) and how readers work

Tagged: , ,

  • 22. February 2017 at 1:59
    Hi,

    I'm working on a project in Australia with a state-wide library system considering MIFARE Classic EV1 1K as their new membership cards. Having spoken to two different vendors, I am confused about using UID and alternative barcode ID, and readers.
    The current system requires the continued use of barcodes/barcode numbers, and I understand that card vendors print the barcodes and store the barcode number on each card chip (and I presume they would provide the chip location where it is stored).

    One vendor has told me the Library Management System must store both the card UID and the barcode number (barcode numbers are used as website login usernames so need to be stored) so that when readers are purchased, they can be 'plug and play' to read the UID, otherwise special software will be needed to read the barcode. He also said if you go the barcode number option with the readers, it bypasses the encryption technologies that is the advantage of using the UID.

    The second vendor has told me that using the stored barcode number on the cards would actually be more secure, and programming the readers to read the barcode number from the card chip location is quite straight forward. That would mean we only need to store the barcode number in the Library Management System. So no use of the UID.

    Additionally, is there a default that readers use - 4b NUID vs 7b UID - which number should be stored in the LMS if that is the better option?

    At this point, the cards would only be used for identification but may be used as access cards later on.

    I'm very confused as getting different information from different people and as you can tell, I'm not a developer or major techie :)
    Would there be someone out there who could explain in simple english the benefits/downfalls of each option?
    Thank you!!!
    + 0  |  - 0

    Re: UID vs alternative ID (barcode) and how readers work

    22. February 2017 at 9:12
    Hello Cath,

    I cannot say anything about barcode readers, sorry but this is not my business.

    Each NFC device has a unique serial number which is 7 bytes long. This serial number also contains a vendor code. 4 bytes serial number was used for the MIFARE Classic products in the past. But 4 byte is not an option today.

    A NFC tag contains memory space which can be used to store more information on the tag, e.g.: internal booking codes, product or catalog IDs, expiring dates etc. Please have a look to this datasheets:

    https://www.nxp.com/documents/data_sheet/NTAG213_215_216.pdf
    http://www.nxp.com/documents/data_sheet/SL2S2002_SL2S2102.pdf

    So, in a real world application you would store the article number on the tag to identify an article. The UID is unique, so the tag could be removed or changed, but the article number will usually not change.

    Regards,
    The TapLinx team
    + 0  |  - 0

    Re: UID vs alternative ID (barcode) and how readers work

    22. February 2017 at 22:28
    Thanks for your reply TapLinx, however I'm not referring to RFID tags, I'm talking MIFARE Classic (ISO 14443) to be used as membership cards. From what I've read, they can currently be supplied with either a 4b NUID (most common) although there is now a 7b UID option.

    We use NFC tags in all our libraries currently for all resources, so am familiar with that technology.
    + 0  |  - 0

    Re: UID vs alternative ID (barcode) and how readers work

    23. February 2017 at 11:23
    What I said: the UID of all contactless products (tags and MIFARE Classic) is 7 byte UID. This is most common. A 4 byte UID was used in the past and is currently available only for customers who must be compatible with old systems. A UID of 4 bytes cannot be unique anymore, the space is already exhausted.

    The TapLinx team
    + 0  |  - 0
Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.