Super Secure Unique ID and Verification concept

[Don_Macaroni]

To all interest in creating a virtually bullet proof Unique ID sequence and reverse checker. I designed this concept for use on rfid cards for an entry system. But it can be implemented with barcodes, as well as reverse checked with PHP in case of a web-based solution.
This concept grown from a need to verify the ID on cards. If you have a unique ID of 12345, a person can create a badge with any numeric sequence. But what if you can, as an added security, verify if the sequence is valid? Came up with the following:

1 Global field with something like this "QYUMGZRIHGHMIQSCEBYCWYWLNIPBCEZZCYBZIKJTGLKWGECGJBBQHXVCJQUHAMGWCOCGIAZNYNNOIJLBOSRVDMRFAVNPCOWFGGXNATEUKNPW" (Needs to be 108 characters long, which is 99+9. This will be the verification string.)
1 Number field which receives "Right ( Random ; 9 )" with a script     (eg. 937493814)
1 Text field which receives a calculation via a script:
     - Split the 9 numbers into 3 sequences   (eg. 937  493  814)
     - For each of the 3 sequences you calculate the character position in the verification string by adding the the third number to the first two. (eg. 93+7     49+3     81+4)     This will never be more than 108.
     - The result of the calculation above is used to look up the letter at the specific location in the global verification string. You will get 3 characters.   (N   X   R)
     - Mix the letters into the numbers to get a beautiful sequence; result 937N493X814R.

This number can be easily reverse engineered and checked for validness. The 108 long string can be used in PHP as a var and used to reverse engineer the unique id, and so check it.
It can be even more secure by giving each 3 digit string its own 108 digit verification string. It can be expanded to be more secure and more complex, but the concept is great. I find this method to be fast and secure, adding more is overkill.
I auto-generated 1000 of these sequences and had them program as the UID on rfid cards. Now when a user scans his rfid card, Filemaker first checks the sequence to see if the card is valid. Then checks photo stored, to image on the security camera.
What I also did was avoid certain letters and numbers from appearing. For example capital O and 0 look alike, as well as capital I and 1. So in my verification strings I don't use them, this keeps the strings nicer.

Only downside is if you loose the 108 digit string you are scr3wed.
Anyone interested in a sample file let me know.

Edited June 26, 2016 by Don_Macaroni

[comment]

Can you explain the purpose of this elaborate exercise? What is this designed to prevent?

[Don_Macaroni]

I sure can... It makes proprietary cards. I implemented this twice. Once in a system where a hotel uses cards to identify pool chairs. I supplied a system and barcode cards. By using this method I forced the customer to buy my cards, because cards with a sequential numbering will not work. And second on a harbor entry system. The system is unmanned and uses rfid cards with my numbers. Prior to the system looking up the person id-ing himself, it checks if the card is one of the system (and not some random id-ed card you can buy anywhere.

It has huge potential and a wide range of implementation. With the 108 digit sequence you make any id card proprietary and protects the vendor from the customer outsourcing elsewhere.

Unless you know the 108 digit key, this can not be guessed. Not in a million years.

Edited June 26, 2016 by Don_Macaroni

[comment]

I would think that if you issue unique IDs, you would keep track of them.

Anyway, if you want to build a "secure" system, you need to learn some basic rules of security first.

15 minutes ago, Don_Macaroni said:

Unless you know the 108 digit key, this can not be guessed. Not in a million years.

I don't need to guess. All I need is to read one of your IDs and I can generate close to 500 others that will pass your verification. For example, given your "937N493X814R" I can generate:

919N493X814R
928N493X814R
946N493X814R
955N493X814R
964N493X814R
973N493X814R
982N493X814R
991N493X814R
919N439X814R
919N448X814R
..

and so on.

 

 

 

[Don_Macaroni]

Because you know the formula stated you can do so. It is up to the programmer to use a formula and verification sequence that is kept secret.

[comment]

17 minutes ago, Don_Macaroni said:

Because you know the formula stated you can do so. It is up to the programmer to use a formula and verification sequence that is kept secret.

Well, for one thing, anyone can read the formula right here in your opening post.

The other thing is that security through obscurity is an illusion.

[Don_Macaroni]

The formula listed is an example of how to implement a long verification string. It is not a login or password, it is an alternative to using sequentially numbered unique ids. It is not meant to give access to anything, therefor your arguments are not valid (they are in their respective sence). As said, I used this method to number 100,000 cards, which belong to a proprietary system I own. To prevent my customer from ordering stock sequentially numbered cards cheap from another source, I invented this. For my customer to discover my formula and 'secret' string to make 100,000 numbers that work would be virtually impossible.

[jbante]

On 26 June 2016 at 0:11 PM, Don_Macaroni said:

For my customer to discover my formula and 'secret' string to make 100,000 numbers that work would be virtually impossible.

Not even close to impossible. Maybe it's more effort than your typical clients are willing to invest, but any competent cryptanalyst would have no problem with this. A more secure approach might be to start with a real-data serial number, run it through a salted hash, and add the hash to the serial number. As long as you keep the salt secret, clients should not be able to reproduce the full value.

A weaker option, but perhaps less effort to implement in FileMaker without a plugin and still stronger than what you have so far, would be to use a basic checksum algorithm instead of a cryptographic hash function:

Let ( [
    _data = Table::serialNumber ;

    _salt = $anyASCIITextYouWant ;

    _checksum = ChecksumCRC16 ( _data & _salt ) ;

    _finalID = _data * 2^16 + _checksum
] ;
    _finalID
)

Edited June 27, 2016 by jbante

[Don_Macaroni]

Got some numbers here, generated in Filemaker with a different formula than described above...

Y74173N355
G06493Y759
G31838W608
T91983H414
W03699M112
X80284G309
U89344M788
H41948W509
J07854R652
X41583B633
W71034X431
T63546G371
A21734J047
A40260U124
G06500Z626
Z70316G696
B44227R409
D95958K519
G37676K811
R64986D515
Y89980P698
E21673G203
J14951M324
H18747J139
C12631G989
N44233Y131
K76552V582
B25520M706
M47966M194
C54096P508
V45181A942
M54891C968
C46686K554
B59307H098
N44677W353
N94671M631
X41505C241
P31948S471
U14764P595
E45007M706

For the ones that want to reverse engineer it to see if it is easy or not, the numbers can be verified here. https://fieldsmedia.com/verify/
I programmed it with PHP, reverse engineering the string.

Another fact is, by using a string longer than the 24 characters used (26 minus the I and O I took out for confusion), the chances are real that certain combinations/calculations are wrong, but result in the same letter. This can be avoided by using double letters instead of one. But as said, this was never intended to secure data from hackers. It is not a password, nor will it give access to the FBI's Area 51 documents. It is a way to generate unique ids that are virtually impossible, or at least very hard, to crack by the average Joe. Also, I have these programmed on an rfid card and they are not displayed in plain text on the card itself. So you would need an rfid reader as well...

I think it is pretty need and very usable for its purpose. Hope it helps somebody with something, you can take this a long way and expand it greatly.

[jbante]

You say that's about security ("virtually bullet proof", you said), then that it's not about security (from someone who knows what they're doing), then that it is about security (from someone who does not know what they're doing). You'll understand my whiplash. Good for you if this solution works for you, but I don't want someone else in the future to find this thread and think your solution is a secure one. You have a good idea, but cryptographers have had similar ideas, and they've spent decades refining them. With a little more effort, there are more secure solutions to the same problem. There are even solutions to the same problem that are more secure and don't require any more effort. Others who have a similar need to yours should consider one of those solutions instead.

Edited June 28, 2016 by jbante

[Don_Macaroni]

Maybe a little too enthusiastic with 'super secure', but thanks to the 'constructive' critics ;-) I was able to better the concept. Random string is checked for doubles prior to being calculated, added double letters to the sequence, made the hash longer and made the calculation more complex.

SQ66450CB119
AM12264BR442
SD76146FA698
FA78819SW656

https://fieldsmedia.com/verify/

If you give away the key of your SSL certificate, hackers can decrypt it and your doomed. Same here, if the calculation and hash are known, it would be an easy game. Hackers will always go for easy pray first, and base their attacks on what's at stake (decrypting chair tags would not be one of them). In this case it is not an easy task discovering a 800+ string hash and calculation. In my opinion the concept of creating secure unique id sequences, as an alternative to 'open' sequentially numbered ones, is great and something to dive into. For example, lot of companies use sequential numbered barcodes as customer ids. This is easy to duplicate and the system will accept it as usual. If the system could check at id scan if a card is genuine or not, that would be great.

[comment]

5 minutes ago, Don_Macaroni said:

If you give away the key of your SSL certificate, hackers can decrypt it and your doomed. Same here, if the calculation and hash are known, it would be an easy game.

No, it's not the same at all.

 

[Don_Macaroni]

I challenge anyone to decrypt this... Even with the verify weblink, which is not available normally, I think it will be hard to impossible. Just added a better hash which adds lower caps and numbers for more randomness.
Oi23825l7455
oP47247E0887
VO957142K378
13739448P283
0f78772Ok163
https://fieldsmedia.com/verify/
 

[jbante]

2 hours ago, Don_Macaroni said:

I challenge anyone to decrypt this...

If you want to pay for a security audit, I'd be happy to make the attempt. It will require more source data, though.

Edited June 29, 2016 by jbante