Originally Posted by 'Aarelan',index.php?page=Thread&postID=216355#post 216355
The fact that our current solution is insensitive to machine configuration changes, and is a user registration rather than a machine registration, was one of the major factors in our decision to go the way we did. We also liked the slick registration process, and that the system would still work if the security server was down.
I think that, even with what we have now, you could firewall the program to satisfy your security requirements. I would suggest this:
The installation requires no connection, and can be fire walled till it squeeks.
The security module and key interceptor module run as two separate processes, and can be identified as such by the fire wall.
The security module is provided by a 3rd party, and does not connect to our site. (I can supply the details if required, so you can check them out)
The key interceptor module (which is the bit that could grab sensitive information) can be blocked. It does attempt to listen on a port, but that's for running linked copies of GCP, and for a single copy, is not required. The security module has no access to the intercepted key data (which, as a matter of interest, is not stored - only the last key is held in memory, so even if something did scan our process memory, it couldn't see a password)
This, should, I think answer your concerns about us stealing your keys. As for your disquiet about being dependent on another service, I'd like it if you'd give it a chance, before deciding it's a bad thing. As I said, I really don't having to use security mechanisms at all, but given the need, I really do think this is the best (or at maybe least bad).
If people do report problems with the security module, we could change it within hours.
Phil