It was discovered that, when sending token refresh requests from the desktop application to the server, the server was attempting to verify that the hardware id and session token were both active in a current session, however, the data that the server was attempting to check the database with had already been decrypted. Redis' cache was able to supply a seemingly normal amount of time during testing for this problem to not occur, but as soon as the cache ran out and the data had to be pulled from the external database, it was attempting to find a decrypted value in the database where all the values were encrypted. The solution to this problem was to store hardware ids in the database decrypted. While the id is unique to your system itself, it does not contain any information that is sensitive and is purely used as an extra step in license verification, and even if someone held both the decrypted hardware id and refresh token, they theoretically would be unable to gain unauthorized access to the program due to additional security measures in place. Incidents like these in the close beta release of the program are bound to occur due to the lack of limited knowledge before opening the doors for faults. We are constantly improving our systems, and we appreciate your patience and feedback.