Jack Cook7 said:It is important to clarify that authentication and authorization are two distinct concepts...
I believe I have grasped the situation... 😉 I don't see authorization being an issue at all. It really just comes down to the underlying code logic—defining exactly which tag ID interacts with which specific function. That way, I can program various cards for different purposes, such as ones that trigger Bluetooth data transfers or master cards that unlock every door on the premises... it’s all about how you decide to engineer it at that level of sophistication...
I am somewhat perplexed by the lack of authentication protocols to verify that the user actually possesses the specific card details I provided, rather than some fraudulent data... it leaves quite a few unanswered questions for me. However, I shall attempt to outline a few possibilities that come to mind...
In principle, I would need to possess some sort of secret key to verify that the card was actually programmed by me—essentially a way to validate my own recorded data. However, I see a significant security flaw here: anyone could potentially scan the card, intercept that secret key, and then the entire system becomes completely compromised...
It seems my only viable path forward is to implement a unique secret key that is tied directly to the specific Tag ID. This means every single card will possess its own distinct secret key, while my software remains the sole entity capable of calculating the relationship between the two... Consequently, once a card is scanned, I will capture both pieces of data and perform a logical validation to ensure the decrypted secret key matches the Tag ID based on our predefined parameters...
If the information matches, the card should be perfectly valid... 🙂
Would that be possible...? 🤔
The only minor oversight remaining is that a user could potentially duplicate or copy cards that successfully pass authentication... however, I do not view this as a significant issue. Since a user cannot use this method to hijack the authority level of someone else's card—they can only replicate their own and perhaps gift it to another—it doesn't pose much of a concern in my estimation...
Furthermore, one could theoretically dismantle the device to inspect the underlying code—assuming that is even feasible—to determine the specific relationship between the secret key and the tag ID. Once that logic is uncovered, it would be possible to manufacture any card one desires. However, I am certainly not designing an ATM security system, so I have no intention of wasting my time on such matters... 😁
...
...
One thing I am still pondering is how much experience serves as our most powerful tool... I find myself wondering how I will truly gauge the long-term stability of these components when exposed to various weather conditions. I am not entirely certain that I will have an adequate testing window, which would be quite inconvenient if everything were to fail prematurely...
During the summer months, one can expect significant exposure to intense heat paired with a certain degree of humidity in the air...
Regarding the current heatwave... It won't be under direct sunlight, but they will still be outside where the summer heat is going to be absolutely brutal. I am not entirely convinced that adding any foam insulation would make much of a difference... If my experience with the local HVAC contractors serves me right, the temperature inside would reach the same level whether the insulation is there or not; the only real change would be a slight delay in how quickly the indoor climate shifts toward the outdoor temperature...
The issue of moisture is likely to be even more problematic...
I am optimistic that humidity levels will remain manageable, though I have noticed a small clip that seems to be "slipping" out from the electronics housing. This suggests that the enclosure cannot be completely airtight. While there will likely be some sort of protective system in place to manage the clip's position, I suspect it won't be perfect, which might allow for some moisture infiltration...
To ensure the design functions correctly, the servo motor must be housed within the casing with a mechanical output that interfaces directly with the clip. However, this specific requirement creates a challenge, as it prevents the servo itself from being hermetically sealed. Once you move past the servo, the ESP32 and the RFID reader can be completely sealed off for protection...
Aside from that, there will also be a collision sensor integrated into the setup—something similar to this: shorturl.at/jnpy0. It won't be possible to keep it completely isolated, as it needs to be positioned right next to the piston to verify its final position...
The sensor is my primary concern because it houses the electrical contacts, and I suspect those components will be particularly vulnerable to humidity.
If we opt for a version with a keypad, those buttons will also be subject to contact issues.
Furthermore, I have doubts regarding whether a standard servo can withstand high temperatures and moisture levels... especially since it relies on moving parts and plastic housing if we were to use this: shorturl.at/HLQW3
It is quite difficult to determine if utilizing a servo under these specific environmental conditions makes sense, especially when expecting a lifespan of at least three years.
I realize these questions might be better suited for a different discussion thread and may feel out of place here... nonetheless, these are the uncertainties weighing on my mind. It would be incredibly helpful if anyone could share insights from practical field projects regarding how these components actually performed in such settings.