técnica tipos simetricos qué para misma huella hashes funciones explicacion ejemplos diferentes crea contraseña asimetricos algoritmos algoritmo algorithm language-agnostic authentication

algorithm - tipos - ¿Algoritmo de autenticación de los pobres?



tipos de funciones hash (13)

Solicitud de tormenta de ideas

Necesito una idea para un algoritmo de autenticación con algunos requisitos inusuales.

El algoritmo se usaría para verificar que el remitente de un mensaje sea legítimo.

Restricciones

  1. La "capa de transporte" es el correo electrónico
    • el remitente ('' Alice '') es un ser humano
    • Alice solo tiene acceso a un navegador web y acceso a Internet (incluida una cuenta de correo web) como sus herramientas; por lo tanto ella no puede hacer cálculos muy complicados
    • El receptor ('' Bob '') es una computadora sin acceso directo desde Internet.
    • Bob tiene una cuenta de correo electrónico que verifica periódicamente.
    • Bob puede enviar un correo electrónico.
    • Sin enviar información a un tercero: Alice y Bob no pueden enviar información fuera de banda. Leer información disponible públicamente (como la hora desde un servidor horario) está bien.

Suposiciones

  • Alice puede acceder a cierta información a nivel local: tal vez lleve una libreta, o incluso podríamos suponer que su cuenta de correo web está protegida contra intrusos, por lo tanto, la información confidencial puede almacenarse allí.
  • Alice y Bob pueden intercambiar información sensible directamente en un momento anterior a la autenticación (¿claves privadas?)

No objetivos:

  • la codificación de la carga real del mensaje no es necesaria.
  • la velocidad / latencia no son (grandes) problemas

Algunas ideas para comenzar:

  1. Claro antiguo contraseña codificada.
    Problemas :

    • ataque de fuerza bruta (no probable)
    • es posible espiar si la comunicación se hace en texto claro, entonces es posible reproducir de nuevo los ataques

  2. Algoritmo simple basado en la fecha / hora actual
    Ejemplo: Alice agrega la fecha, hora y minuto actuales y envía el resultado como el token de autenticación, que Bob puede verificar. Supongamos que el acceso de solo lectura a un servidor horario no infringe la regla n. ° 7 (ningún tercero).
    Problemas :

    • seguridad a través de la oscuridad : el algoritmo es algo seguro solo porque no está disponible públicamente (bueno, ahora es ... ¡Uy!)

  3. Algún tipo de mecanismo de desafío y respuesta: Alice envía una solicitud de autenticación, Bob responde con un desafío, Alice envía la respuesta esperada y la carga real.
    ¿Cuáles son los detalles del mecanismo? No lo sé :)

¿Qué puedes pensar? Espero ver algunas respuestas creativas ;-)

Editar:

Tal vez un ejemplo haga que la regla n. ° 3 sea más clara: supongamos que Alice está usando un dispositivo patentado de código cerrado <cough> iPhone <cough> para acceder a Internet, o está de pie frente a un quiosco público de Internet.

¿Me falta algo obvio al sugerir una simple clave pública / privada y firmar el correo electrónico?

Firefox tiene al menos una extensión para permitir GPG en webmail.

Aquí hay otra sugerencia:

  • Comience con el intercambio de claves Diffie-Hellman , lo que da como resultado una clave privada compartida, conocida solo por presumiblemente Alice y Bob .
  • Tener una contraseña predefinida conocida solo por Alice y Bob .
  • Haga que Alice encripte la contraseña usando la clave compartida y se la envíe a Bob
  • Ahora Bob puede ver que, presumiblemente, Alice realmente es Alice .

Problemas:

  • Diffie-Hellman no es seguro usando números pequeños.
  • ¿Qué sería un algoritmo de cifrado simétrico simple (para encriptar la contraseña)?

Considere crear una página web que contenga el algoritmo como JavaScript, posiblemente como una descarga (para que pueda descargarlo una vez y llevarlo en una unidad USB).

La idea es que abra la página, verifique el código fuente (todos los JavaScript deben estar en línea) y luego ingrese su contraseña en un campo de texto en la página. El JavaScript traducirá esto en un código a medida que escribe (por lo que no habrá tráfico de red mientras lo hace; si lo hubiera, podría haber un keylogger ejecutándose en segundo plano).

Después de que ella tenga el código, puede copiarlo en alguna parte.

JavaScript puede usar la hora actual como una semilla. Corta la hora actual en intervalos de cinco minutos. La mayoría de las veces, usar la hora actual será suficiente para decodificar la contraseña y, si está cerca del inicio del intervalo de cinco minutos, intente con la anterior.

Consulte este sitio para ver un ejemplo: https://www.pwdhash.com/

Dos opciones que puedo pensar:

  • Emita una tarjeta con contraseñas de un solo uso (comunicación antes del hecho, cuaderno)
  • Dispositivo electrónico que produce códigos PIN (evita ataques de repetición)

Hmm ... ¿esto contaría como una tercera parte?

Configura un hermano de Bob - Charlie, al que se puede acceder desde Internet a través de HTTPS. Para enviar un mensaje a Bob, Alice primero tendría que iniciar sesión en Charlie (a través de una contraseña antigua) y luego Charlie le otorgaría una ficha de un solo uso. Luego envía su correo electrónico junto con la ficha a Bob.

La solución más simple es hacer que Bob envíe correos periódicamente a la cuenta de correo de Alice. Cuando necesita algo de Bob, tiene que responder usando uno de estos correos. Bob puede poner algunos tokens de cheques en el correo (identificación del correo, o una cadena que debe repetirse en el asunto o el cuerpo del correo).

Al igual que muchos de los esquemas de verificación de correo electrónico funcionan.

Desventaja: esto solo prueba que el atacante tiene acceso a la cuenta de correo de Alicia, no que en realidad es la propia Alicia. Para solucionar esto, podría decirle a Alice una contraseña y usar el truco de la "página HTML de JavaScript" para que pueda codificar la clave de Bob usando su contraseña.

Esto probaría que ella tiene acceso a su cuenta de correo y que conoce la contraseña.

Si Alice puede ejecutar código en su equipo (por ejemplo, usando JavaScript que se encuentra en algún sitio público, como: http://www.functions-online.com/en/sha1.html ), puede recibir el desafío, hash. junto con la contraseña, y enviarlo de vuelta.

Si no va a utilizar PKI, que es por lejos la mejor solución, intente utilizar un sistema de desafío-respuesta como CRAM-MD5 (aunque sugeriría un algoritmo de resumen diferente).

Sus limitaciones hacen que la implementación de un sistema criptográfico seguro sea casi inviable. ¿No hay nada que puedas hacer para cambiar el transporte?

Una manera simple de proteger los datos en tránsito sin intercambiar contraseñas es el XOR de tres vías:

  1. Alice crea algunos bytes usando su propia clave.
  2. Ella XOR los datos con estos bytes para que sean ilegibles.
  3. Alice envía los datos encriptados a Bob
  4. Bob crea algunos bytes usando su propia clave.
  5. Él XORs los datos con estos bytes.
  6. Bob envía los datos de doble cifrado a Alice
  7. Alice aplica su patrón XOR una vez más. Ahora, los datos solo están codificados con el patrón de Bob
  8. Alice envía los datos a Bob
  9. Bob ahora puede decodificar los datos con su propio patrón

Mi idea de un mecanismo de desafío y respuesta de baja tecnología amigable para los seres humanos:

  1. Bob cambia el desafío cada vez que recibe un mensaje válido (por ejemplo, hace un hash salado de la hora actual)
  2. cada mensaje inválido enviado a Bob lo hace responder con el desafío actual, por lo que Alice puede consultarlo enviando un correo vacío
  3. una vez que Alicia conoce el desafío, va a https://www.pwdhash.com/
    • en "Dirección del sitio", ella ingresa al desafío actual
    • en "Contraseña del sitio" ingresa su contraseña personal (que Bob conoce)
    • PwdHash genera una "contraseña hash"
  4. Alice escribe un mensaje a Bob, usando el hash recién creado como el sujeto
  5. Bob recibe el mensaje, evalúa el desafío actual y la contraseña de Alice de acuerdo con el algoritmo PwdHash, y ve si su resultado coincide con el asunto del mensaje
  6. si lo hace, Bob acepta el mensaje y envía una confirmación que contiene el nuevo desafío (esencialmente este es el paso 1)

Ventajas:

  • barato y simple, incluso se puede ejecutar en dispositivos móviles razonablemente modernos
  • amigable para los humanos (sin matemática, fácil de recordar, requisitos previos fácilmente disponibles en la red)
  • no hay ataque de repetición posible
  • sin contraseñas de texto claro sobre el cable
  • no se queda sin contraseñas (como hacen los pads de una sola vez)
  • no hay límites de tiempo inherentes (como los tokens RSA tienen)
  • el sitio web PwdHash puede guardarse en el disco y llamarse localmente, sin dependencia de terceros aquí

Desventajas:

  • Bob y Alice deben compartir previamente una clave (la contraseña de Alice), por lo tanto, Alice no puede cambiar su contraseña fuera del sitio.
  • comprometer la contraseña de Alice es el vector de ataque más fácil (pero ese es el caso con casi todos los sistemas protegidos por contraseña)

Tenga en cuenta que PwdHash es un algoritmo hash abierto, Bob puede implementarlo fácilmente. El sitio web PwdHash funciona sin post-backs, todo es solo JavaScript del lado del cliente, no quedan rastros.

Elaborando en lassevks respuesta :

En mi empresa utilizamos tokens SecurID de RSA para autenticación remota.

Le da un número de 6 dígitos que cambia cada 60 segundos como un token de autenticación, supuestamente su generador de tokens y el servidor son los únicos en el universo que conocen el token que es válido en este momento.

Como una alternativa de baja tecnología, se le puede dar a Alice un conjunto de n (10, 20, 100 - lo que sea razonable en su caso específico) códigos de autenticación de una sola vez. Le pediría un código específico (por ejemplo, el número 42 en la lista). Después de usar este código, se vuelve inválido para un uso posterior.

Editar: Consulte la respuesta de lacop para una buena implementación de la solución de baja tecnología.