Here's the problem: if you care about security to the point where screen locks are serious business, you've gotten yourself into a contradictory set of requirements: both trusted and untrusted users have physical access to and execution priveleges on a terminal. If you really suspect that your users are untrustworthy enough to steal credentials in this way, the answer is to not have a screenlock at all but to push the security barrier further into the system. The terminal is dumb and has no security model, but to access and/or interact with your proprietary information, the user types credentials into your own custom coded application or web form through a browser and it logs him out after N minutes and requires reentry of the credentials. He's not allowed to run any code on your system, and all the directories, executables and shell scripts that are run in the course of interactring with the terminal are marked 755 or 744 as appropriate so that he can't modify them, and the tmp dir resides in a ramdisk that gets wiped between sessions. Then it doesn't matter if everything is permitted over the X11 protocol, because there is no way to spoof anything from that untrusted terminal. Physical security goes a long way in obviating risks from software vulnerabilities, where practical. And if the data being guarded is sufficiently important, it will be made to be perceived as practical.