Your problem is that the login is basically meaningless for your threat model. Make it mean something and your problem will cease to exist, or change your threat model and the problem will cease to be one.

If you want to secure access to the data dll but users authenticate themselves to another dll then some sort of communication has to occur between those two dlls, either directly or indirectly (by passing along a ticket, security context object reference, login handle, whatever).

For normal apps you can get away with having some sort of global 'security context' since there is only one interactive user; the data dll could query the security dll for the credentials/access level of the currently logged-in user.

Note: what you described is commonly called a 'replay attack' and it can be avoided by using seeding, for example.

However, since you seem to be using Fox for generating the dlls you can basically forget about security - anybody can decompile the dlls to nicely formatted Fox source code and discover their communication protocol. So you probably need to adjust not only your security implementation but also your threat model in some fashion; no security scheme implemented in Fox alone can hold off a clued attacker for more than a few minutes if they have access to the executable.