A step in the right direction. How about adding additional checking to ensure the user is who they say they are. For instance. SQL Server run in a corporate environment behind a firewall could lock down accounts using constantly changing passkeys that exist only for a short duration and are placed in a random folder that exists for a short duration. The verification process would look at the location of the passkey as well as the passkey. If the user logging in is not on the local network, then the passkey was hijacked and the logon attempt would fail and access would be denied. This also assumes that the validation process will pass the encrypted location of the passkey to the client and the client must have access that location and that removes the outside world from the picture. There would be a lot of protocol happening during this whole process, using the previous passkey to decrypt the location so that the client can send a validation request to the server in a timely manner so that the server won't reject the login attempt.

For the outside world, a similar process but using a slightly different approach - which I haven't really concentrated on yet!

There has been a lot of conversation covering this topic falling under different ideas ranging from loginless access to network security. I think three random 128 bit encrypted passkeys that change with every login would be the good deterrent. That would mean a multipass verification process. To continue to the next level of the login process, the previous part must pass and so forth. The question is how many levels of validation is enough while also realizing that at some point in this process we will have the weakest link and that would be in the client application.

Just my two cents worth.