How can I use Delphi to create a visual challenge / response for restoring access to an application?

I'm interested in creating a challenge / response type process in Delphi. The scenario is this...we have 2 computers...1 belongs to the user and 1 belongs to a support technician.

The user is locked out of a certain program, and in 开发者_Python百科order to gain 1 time access, I want:

1. The user to be presented with a challenge phrase, such as "28394LDJA9281DHQ" or some type of reasonably unique value
2. The user will call support staff and read this challenge (after the support staff has validated their identity)
3. The support person will type this challenge value into a program on their system which will generate a response, something equally as unique as the response, such as "9232KLSDF92SD"
4. The user types in the response and the program determines whether or not this is a valid response.
5. If it is, the user is granted 1 time access to the application.

Now, how to do this is my question? I will have 2 applications that will not have networked access to one another. Is there any functionality within Windows that can help me with this task?

I believe that I can use some functionality within CryptoAPI, but I really am not certain where to begin. I'd appreciate any help you could offer.

I would implement a MD5 based Challenge-Response authentication.

From wikipedia http://en.wikipedia.org/wiki/CRAM-MD5

Protocol

1. Challenge: In CRAM-MD5 authentication, the server first sends a challenge string to the client.
2. Response: The client responds with a username followed by a space character and then a 16-byte digest in hexadecimal notation. The digest is the output of HMAC-MD5 with the user's password as the secret key, and the server's original challenge as the message.
3. Comparison: The server uses the same method to compute the expected response. If the given response and the expected response match then authentication was successful.

This provides three important types of security.

1. First, others cannot duplicate the hash without knowing the password. This provides authentication.
2. Second, others cannot replay the hash—it is dependent on the unpredictable challenge. This is variously called freshness or replay prevention.
3. Third, observers do not learn the password. This is called secrecy.

The two important features of this protocol that provide these three security benefits are the one-way hash and the fresh random challenge.

Additionally, you may add some application-identification into the challenge string, for a double check on the sender of the challenge.

Important: it has some weaknesses, evaluate carefully how they may affect you.

Regarding the verbal challenge/response strategy: We used this approach to license a niche application on five thousand workstations world-wide for more than ten years. Our support team called it the "Missile Launch Codes" because of its similarity to the classic missile launch authentication process seen on old movies.

This is an extremely time consuming way to protect your program. It consumed enormous amounts of our staffs' and customers' time reading the codes to and from users. They all hated it.

Your situation/context may be different. Perhaps you won't be using it nearly as frequently as we did. But here are some suggestions:

1. Carefully consider the length and contents of the code: most users (and support staff) resent typing lots of characters. Many users are bad typists. Consider whether a long string and including punctuation marks and case sensitivity unduly burdens them compared to the amount of security added.

2. After years of using a verbal challenge/response implementation, we left it in place (as a fall-back) but added a simple automated system. We chose to use FTP rather than a more sophisticated web approach so that we didn't have to have any software running on our in-house server (or deal with our IT staff!)

Basically, we use FTP files to do the exchange that was previously done on the phone. The server places a file on the FTP server containing the challenge phrase. The file's name is the customer's name. Our support staff have a program that automatically creates this file on our ftp site.

The customer is instructed by our staff to hit a hot key that reads the FTP file, authenticates it, and places a response file back on the server.

Our support staffs' software has been polling waiting for the customer's software to create the response file. When it sees the file, it downloads it and confirms its contents, and deletes it from the server.

You can of course have this exchange happen as many times and in either direction as you need in a given session in order to accomplish your goals.

The data in the files can have the same MD5 keys that you would use verbally, so that it is as secure as you'd like.

A weakness in this system is that the user has to have FTP access. We've found that the majority of our users (all businesses) have FTP access available. (Of course, your customer base may not...) If our application in the field is unable to access our FTP site, it clearly announces the problem so that our customer can go to their IT staff to request that they open the access. Meanwhile, we just fall back to the verbal codes.

We used the plain vanilla Indy FTP tools with no problem.

No doubt there are some weaknesses in this approach (probably including some that we haven't thought of.) But, for our needs, it has been fantastic. Our support staff and customers love it.

Sorry if none of this is relevant to you. Hope this helps you some.