Security and cheats: How DeviceFingerprint stops people from playing me for a fool (Part 5/5)
If you give a team of developers and producers a web portal to clock in, I guarantee that in less than 24 hours someone will try to build a script to clock in from their bed. Welcome to the Final Chapter.
The problem of digital trust
When I released the rh_mexico portal, I knew geolocation alone wasn't enough. Spoofing GPS location on a phone or web browser is easier than basic math. Anyone with a Chrome extension or a Fake GPS app can simulate being at the Polanco office while still in pajamas at home in Satelite.
DeviceFingerprint to the rescue
To prevent this, I implemented the DeviceFingerprint service. I don't just trust the coordinates sent by the browser; I do a passive scan of the device making the request.
What does the system check?
1. Network inconsistency: If the public IP says you are on a residential Totalplay network, but the GPS says you are in the middle of a festival field, we have a problem.
2. Hardware/browser signatures: We generate a hash with the User Agent, screen resolution, installed plugins, and time zone. If a user who always clocks in from an iPhone 14 suddenly sends a check-in from a generic Linux box, the system raises a red flag (flagged_for_review).
3. JWT Validation and Dynamic Tokens: Every request to the AsistenciaProcessor is signed with a short-lived token generated by the ApiTokenValidator. You can't just do a replay attack using curl from a terminal.
Conclusion
At the end of the day, building rh_mexico on Drupal took way more time than just paying for a Buk subscription or any other generic crap. But the result is a system that is 100% ours, that respects the chaotic way an events agency operates, and that automates the bureaucracy so we can focus on what matters.
End of story. If you liked the series, hit me up on X or wherever you read this. Peace.