¿Cómo puedo usar Delphi para crear un desafío/respuesta visual para restaurar el acceso a una aplicación?

Question

Estoy interesado en crear un proceso tipo desafío/respuesta en Delphi.El escenario es este... tenemos 2 computadoras... 1 pertenece al usuario y 1 pertenece a un técnico de soporte.

El usuario está bloqueado de un determinado programa y, para obtener acceso por primera vez, quiero:

1. Al usuario se le presentará una frase de desafío, como "28394LDJA9281DHQ" o algún tipo de valor razonablemente único.
2. El usuario llamará al personal de soporte y leerá este desafío (después de que el personal de soporte haya validado su identidad)
3. La persona de soporte escribirá este valor de desafío en un programa de su sistema que generará una respuesta, algo tan único como la respuesta, como "9232KLSDF92SD".
4. El usuario escribe la respuesta y el programa determina si es una respuesta válida o no.
5. Si es así, al usuario se le concede acceso por única vez a la aplicación.

Ahora, ¿cómo hacer esto es mi pregunta?Tendré 2 aplicaciones que no tienen acceso en red entre sí.¿Existe alguna funcionalidad dentro de Windows que pueda ayudarme con esta tarea?

Creo que puedo utilizar alguna funcionalidad dentro CriptoAPI, pero realmente no estoy seguro de por dónde empezar.Agradecería cualquier ayuda que pudiera ofrecer.

Answer 1

Implementaría una autenticación de respuesta de desafío basada en MD5.

De Wikipedia http://en.wikipedia.org/wiki/cram-md5

Protocolo

1. Desafío: en la autenticación Cram-MD5, el servidor primero envía una cadena de desafío al cliente.
2. Respuesta: El cliente responde con un nombre de usuario seguido de un personaje espacial y luego un resumen de 16 bytes en notación hexadecimal. El Digest es la salida de HMAC-MD5 con la contraseña del usuario como clave secreta y el desafío original del servidor como mensaje.
3. Comparación: el servidor utiliza el mismo método para calcular la respuesta esperada. Si la respuesta dada y la respuesta esperada coinciden, la autenticación fue exitosa.

Esto proporciona tres tipos importantes de seguridad.

1. Primero, otros no pueden duplicar el hash sin conocer la contraseña. Esto proporciona autenticación.
2. En segundo lugar, otros no pueden reproducir el hash: depende del desafío impredecible. Esto se llama frescura o prevención de reproducción.
3. Tercero, los observadores no aprenden la contraseña. Esto se llama secreto.

Las dos características importantes de este protocolo que proporcionan estos tres beneficios de seguridad son el hash unidireccional y el nuevo desafío aleatorio.

Además, puede agregar alguna identificación de aplicación a la cadena de desafío, para una doble verificación del remitente del desafío.

Importante: tiene algunas debilidades, evalúa cuidadosamente cómo pueden afectarlo.

Answer 2

Con respecto a la estrategia verbal de desafío/respuesta: utilizamos este enfoque para licenciar una aplicación de nicho en cinco mil estaciones de trabajo en todo el mundo durante más de diez años. Nuestro equipo de soporte lo llamó los "códigos de lanzamiento de misiles" debido a su similitud con el clásico proceso de autenticación de lanzamiento de misiles que se ve en películas antiguas.

Esta es una forma extremadamente lento de proteger su programa. Consumió enormes cantidades de tiempo de nuestro personal y de los clientes al leer los códigos hacia y desde los usuarios. Todos lo odiaron.

Su situación/contexto puede ser diferente. Quizás no lo uses con tanta frecuencia como nosotros. Pero aquí hay algunas sugerencias:

1. Considere cuidadosamente la longitud y el contenido del código: la mayoría de los usuarios (y el personal de soporte) se resientan de escribir muchos caracteres. Muchos usuarios son mecanógrafos malos. Considere si una cadena larga e incluyendo signos de puntuación y sensibilidad de casos los abarca indebidamente en comparación con la cantidad de seguridad agregada.

2. Después de años de utilizar una implementación verbal de desafío/respuesta, lo dejamos en su lugar (como un retroceso) pero agregamos un sistema automatizado simple. Elegimos usar FTP en lugar de un enfoque web más sofisticado para que no tuviéramos que tener ningún software que se ejecute en nuestro servidor interno (¡o tratar con nuestro personal de TI!)

Básicamente, usamos archivos FTP para hacer el intercambio que se realizó anteriormente en el teléfono. El servidor coloca un archivo en el servidor FTP que contiene la frase de desafío. El nombre del archivo es el nombre del cliente. Nuestro personal de soporte tiene un programa que crea automáticamente este archivo en nuestro sitio FTP.

Nuestro personal le indica al cliente que presente una clave caliente que lea el archivo FTP, lo autentica y coloca un archivo de respuesta en el servidor.

El software de nuestro personal de soporte ha estado encuestando esperando que el software del cliente cree el archivo de respuesta. Cuando ve el archivo, lo descarga y confirma su contenido, y lo elimina del servidor.

Por supuesto, puede hacer que este intercambio ocurra tantas veces y en cualquier dirección como necesite en una sesión determinada para lograr sus objetivos.

Los datos en los archivos pueden tener las mismas claves MD5 que usaría verbalmente, para que sea tan seguro como desee.

Una debilidad en este sistema es que el usuario debe tener acceso FTP. Hemos descubierto que la mayoría de nuestros usuarios (todas las empresas) tienen acceso FTP disponible. (Por supuesto, su base de clientes puede no ...) Si nuestra aplicación en el campo no puede acceder a nuestro sitio FTP, anuncia claramente el problema para que nuestro cliente pueda ir a su personal de TI para solicitar que abra el acceso. Mientras tanto, solo recurrimos a los códigos verbales.

Utilizamos las herramientas FTP de vainilla indy sin problemas.

Sin duda, hay algunas debilidades en este enfoque (probablemente incluyendo algunas en las que no hemos pensado). Pero, para nuestras necesidades, ha sido fantástico. A nuestro personal de apoyo y a los clientes les encanta.

Lo siento si nada de esto es relevante para ti. Espero que esto te ayude a algunos.