¿Cómo se inscriben los clientes con SRP?

Ninguna de esas opciones es excelente, aunque (1) es la peor. La conclusión es que SRP es una idea fantástica, pero es difícil ver cómo implementarla. Especialmente porque la compatibilidad con los navegadores es parcheada: complementos de calidad beta para varios navegadores.

Si desea crear un sitio de trabajo práctico ahora, use (3).

Podrías, en teoría, utilizar (2) sobre SSL con Diffie-Hellman anónimo, por lo que no hay CA. En ese caso, en su primer intercambio, no sabe con quién está hablando. Pero en el futuro, al menos, está seguro de que es el mismo sitio. Entonces, tal vez se registre al principio sin confianza en el sitio, genere confianza con el tiempo y tenga la confianza de que un atacante no podría hacerse pasar por el sitio en el que ahora confía.

Plantea algunos problemas de confianza más amplios y cómo realiza transacciones en línea. A muchos consumidores les gusta el modelo de "Sé que Amazon es confiable, quiero usarlos" y el modelo de CA existente coincide bastante bien. Si le interesan más los arreglos entre pares y no jerárquicos, ¿cómo puede establecer confianza en línea?

Su pregunta solo cubre el registro en línea; si tiene otro acuerdo, como el registro en persona, es posible que tenga mejores opciones.

Primero, dado que los navegadores no admiten SRP, necesariamente estamos hablando de una aplicación local personalizada.

Por seguridad, es importante que el código de la aplicación local sea "seguro". Debemos asumir que el usuario inicialmente no tenía la aplicación, luego la obtuvo y la instaló en su computadora. Esto debe ocurrir antes de la inscripción en SRP. Y, sin embargo, los usuarios deben tener una forma de asegurarse de que el código de la aplicación que instalan sea el genuino, no hostil. Tal vez lo obtuvieron de un CDROM / DVD; tal vez lo descargaron a través de un "canal seguro"; tal vez el binario está firmado. El atacante quisiera insertar su propio código en esa aplicación, por lo que DEBE haber algún mecanismo para derrotar al atacante en ese momento.

Suponiendo que el código de la aplicación es seguro, entonces el código de la aplicación puede incrustar una copia de una clave pública de su servidor; p.ej. Una copia del certificado del servidor. Ese certificado puede ser autofirmado o emitido por una CA personalizada, o lo que sea: ya que la aplicación conoce a priori la clave pública del servidor, puede establecer un túnel seguro con el servidor a través de SSL y sin involucrando a una CA externa: la aplicación solo comprueba que el certificado utilizado por el servidor es bit a bit idéntico al incorporado. En ese momento, puede transmitir cualquier contraseña elegida por el usuario sin temor a escuchas hostiles. Podría decirse que también podría seguir usando ese SSL y no hacer ningún SRP en absoluto.

El modelo de "clave pública incorporada" es simple y funcionará, es decir, si no funciona, significa que tienes un problema de seguridad mayor que no puedes resolver con cualquier cantidad de SRP.

Como nota al margen, este ejemplo muestra que SRP, a pesar de ser un algoritmo masivamente sencillo, no es necesariamente útil en contextos donde el código de aplicación personalizado y específico del servidor está instalado en el lado del cliente. La verdadera bondad de SRP ocurre cuando el código del cliente es genérico , por ejemplo. es un navegador web que no incluye ningún código específico del sitio. Pero no estamos allí todavía; los navegadores no saben cómo hacer SRP (por el momento ...).

O:

4. el cliente registra el verificador usando TSL usando un certificado autofirmado.
5. el cliente registra el verificador cifrado con una clave pública RSA de vainilla de servidores.

Una pregunta relacionada habla sobre estas opciones en enlace

En el contexto de SRP como prueba de contraseña para un sitio web, lo ideal es utilizar un certificado firmado por CA y HTTPS para garantizar que el usuario se está registrando con el servidor correcto. También puede usar HTTPS al iniciar sesión para proteger la identidad del usuario. Entonces tienes defensa en profundidad. Si no desea utilizar un certificado firmado por CA, entonces uno autofirmado puede evitar la interceptación del verificador y el nombre de usuario, pero el usuario corre más riesgo de registrarse en un sitio falso. Hay muchas razones para no confiar solo en TSL y ver que SRP es complementario para usar ambos (por ejemplo, Heartbleed ) pero eso es un poco fuera de tema a la pregunta. La conclusión es que si la contraseña no tiene que copiarse en la memoria del servidor, realmente no debería ser.

La característica de que "no necesita una autoridad externa" es un ángulo que SRP como una extensión de TSL en RFC 5054 ha tomado y que AFAIK no está siendo ampliamente adoptado. Esto puede deberse a que los administradores de sistemas y los desarrolladores se sienten muy cómodos con TSL / HTTPS y certificados y se sienten muy incómodos con probar algo nuevo. La conclusión es que el SRP para TSL reemplaza "tengo que obtener un certificado firmado" por "tengo que distribuir los verificadores de forma segura" y eso implica PKI, por qué no usar los certificados firmados por CA estándar con TLS y estar en una buena posición. configuración documentada? El costo de un certificado firmado solía ser una barrera, pero he comprado los oficiales para los bancos a costos exorbitantes, pero también compré los personales por tan solo $ 25 de CA bastante dudosos. Entonces, realmente, el ángulo de "no necesita una CA" para el SRP tal vez no sea un controlador tan convincente para su adopción hoy en día como podría haber parecido en su invención. También crea un estado de ánimo "ya sea / o" y la gente debería utilizar de forma predeterminada el uso de ambos ; use CA TSL para evitar la intercepción y para ayudar contra el phishing y SRP como prueba de contraseña para evitar que se filtre la contraseña en el servidor y para defenderse de indagación de proxies web corporativos .

Crea una clave privada con el verificador correspondiente para el servidor. En lugar de usar un hash de un salt y una contraseña como en el típico SRP, solo use un número aleatorio (mod N) y no cero para el valor clave. En las implementaciones de SRP, la clave se suele llamar "x" y luego el verificador es g ^ x (mod N).

SRP con una clave de 0 es simplemente Diffie-Hellman.

Ahora haga un inicio de sesión SRP con los roles invertidos: el cliente juega al servidor, el servidor juega al cliente, el servidor "inicia sesión" en el cliente usando la clave privada del servidor, el cliente autentica el servidor con el verificador público del servidor.

Use la clave acordada (establecida por el protocolo SRP) para cifrar la sesión en la que el cliente envía el nuevo verificador del cliente (NO la contraseña) al servidor. Normalmente, el servidor enviará los valores correctos de N y g (que pueden ser diferentes de los N yg utilizados para establecer la identidad del servidor) más un salt aleatorio, luego el cliente utiliza un hash del salt y la contraseña como la nueva llave.

Tenga en cuenta que el verificador del servidor puede ser un valor público, por lo que se puede incrustar en su código en el lado del cliente sin ofuscación. Dado que se creó utilizando un número aleatorio grande y no una contraseña, no es posible atacar el diccionario, por lo que es seguro ser público. La clave privada, por supuesto, debe mantenerse segura en el servidor, ya que cualquier persona con esa clave puede hacerse pasar por ese servidor.