Buenas matake un placer volverte a ver por aquí, un tema bonito el de la autenticación:

Pongamos que conocemos el user/password de cualquier usuario que utilice tu servicio:

- Tarjeta de coordenadas: ampliamente utilizada como sistema de doble autenticación en Bancos y otras entidades. Al introducir users/password te piden una o varias coordenadas de la misma. Los riesgos son la generación de la matriz o el robo de la tarjeta. Si la generación no tiene ninguna tendencia o vulnerabilidad entonces todo iría bien. Para ello utiliza un espacio numérico para cada coordenada digno y pide tres coordenadas distintas al azar. Si tenemos 20 coordenadas cada una con números entre 10^4 y 10^5 - 1 (entre 10.000 y 99.999), el espacio número por coordenadas es de 89.999. Teniendo en cuenta que las coordenadas que se le piden al usuario son distinas (no se repiten) nos queda una Combinación sin repetición de 20 tomando 3 (C(20,3) ): que son 1140 posibilidades con las que puedes jugar. El atacante por cada coordenada tiene una probabilidad de acierto de , son 3 coordenadas por lo tanto . La probabilidad de acierto por intento es nula, en cada intento cambias la coordenada a pedir y ya. El espacio numérico puede ser inferior.

- Shamir's secret sharing: utilizado para dividir un secreto en n partes donde k participantes pueden reconstruirlo. En este caso n=k puesto que sólo quieres que el usuario y el servidor lo reconstruyan, nadie más interviene en el esquema que desarrollas. Cosas a tener en cuenta. Los coeficientes del polinomio de descartan al generar por primera vez el secreto y deben de ser aleatorios y menores que el módulo primo p. El secreto es conocido por el servidor, así que hashealo y cada vez que lo reconstruyas comparas hashes. El servidor genera {f,a,b,p,s} siendo s el secreto, hashea el secreto lo mete a la DB y evalúa f (la función) en 1 y 2, se queda el valor (1,f(1),p), envía al usuario (2,f(2),p) y el resto lo descarta. todo esto al registrarse el usuario por primera vez. Entonces cuando el usuario inicie sesión enviará su secreto y el servidor con el otro secreto generará un sistema lineal de ecuaciones donde hallará la solución exacta al secreto original. Que sucede aquí, pues que si al usuario le roban su secreto GAME OVER.

- PKI: Cada vez que un usuario se registra se le asigna un certificado de cliente emitido por la entidad certificadora (CA) del servidor. El servidor guarda la clave pública del usuario en la DB. Cada vez que el usuario inicie sesión enviará el certificado de usuario (realmente se dice cliente) y con el mismo unos parámetros dependiendo del algoritmo asimétrico. El server validará el certificado: comprobará que fue firmado por su entidad certificadora y que conoce la clave pública. Después comprobará la firma digital sobre los parámetros enviados y si la validación es correcta habra autenticado al cliente. PROBLEMAS: si le roban la clave privada al usuario -> GAME OVER. Por lo tanto lo óptimo es que el user cifre la private con una clave simétrica.

Espero haberte servido de ayuda, cualquier cosa me dices.

Saludos!