Protocolo de contraseña remota segura

El protocolo Secure Remote Password ( SRP ) es un protocolo de intercambio de claves autenticado por contraseña (PAKE) aumentado , diseñado específicamente para sortear las patentes existentes. ^{[ 1 ]}

Como en todos los protocolos PAKE, un intruso o un atacante intermediario no puede obtener suficiente información para adivinar una contraseña mediante fuerza bruta ni aplicar un ataque de diccionario sin interactuar con las partes involucradas en cada intento. Además, al tratarse de un protocolo PAKE aumentado, el servidor no almacena datos equivalentes a la contraseña. ^{[ 2 ]} Esto significa que un atacante que robe los datos del servidor no puede hacerse pasar por el cliente a menos que primero realice una búsqueda de la contraseña mediante fuerza bruta.

En términos sencillos, durante la autenticación SRP (o cualquier otro protocolo PAKE), una parte (el "cliente" o "usuario") demuestra a la otra parte (el "servidor") que conoce la contraseña, sin enviar la contraseña en sí ni ninguna otra información que permita deducirla. La contraseña nunca sale del cliente y es desconocida para el servidor.

Además, el servidor también necesita conocer la contraseña (pero no la contraseña en sí) para establecer la conexión segura. Esto significa que el servidor también se autentica ante el cliente, lo que previene el phishing sin depender de que el usuario analice URL complejas.

La única propiedad de seguridad matemáticamente probada de SRP es que es equivalente a Diffie-Hellman contra un atacante pasivo . ^{[ 3 ]} Si bien es maduro y está ampliamente implementado, SRP es un diseño antiguo con algunas variantes que muestran debilidades sutiles; no es seguro para comunicaciones unificadas , carece de resistencia a todos los ataques de precomputación , tiene pruebas formales más débiles y no ofrece protección contra ciertos modelos de ataque modernos. Por estas razones, SRP ahora se considera en gran medida superado. OPAQUE es el PAKE aumentado preferido, mientras que CPace o SPAKE2 son preferidos para escenarios PAKE equilibrados donde ambas partes comparten la contraseña. ^{[ 4 ] [ 5 ]}

El protocolo SRP posee varias propiedades deseables: permite que un usuario se autentique ante un servidor, es resistente a ataques de diccionario perpetrados por un intruso y no requiere un tercero de confianza . Transmite eficazmente una prueba de contraseña de conocimiento cero del usuario al servidor. En la revisión 6 del protocolo, solo se puede adivinar una contraseña por intento de conexión. Una de las propiedades interesantes del protocolo es que, incluso si se atacan una o dos de las primitivas criptográficas que utiliza, sigue siendo seguro. El protocolo SRP ha sido revisado varias veces y actualmente se encuentra en la revisión 6a.

El protocolo SRP crea una clave privada de gran tamaño compartida entre ambas partes, de forma similar al intercambio de claves Diffie-Hellman. El cliente posee la contraseña del usuario y el servidor un verificador criptográfico derivado de ella. La clave pública compartida se deriva de dos números aleatorios, uno generado por el cliente y otro por el servidor, que son únicos para cada intento de inicio de sesión. En los casos en que se requieren comunicaciones cifradas y autenticación, el protocolo SRP es más seguro que el protocolo SSH y más rápido que el intercambio de claves Diffie-Hellman con mensajes firmados. Además, a diferencia de Kerberos , es independiente de terceros .

El protocolo SRP, versión 3, se describe en RFC 2945. La versión 6a de SRP también se utiliza para la autenticación de contraseñas fuertes en SSL/TLS ^{[ 6 ]} (en TLS-SRP ) y otros estándares como EAP ^{[ 7 ]} y SAML , y forma parte de IEEE 1363.2 e ISO/IEC 11770-4.

En esta descripción del protocolo, versión 6, se utiliza la siguiente notación:

• Se eligen q y N = 2q + 1 de manera que ambos sean primos (lo que hace que q sea un primo de Sophie Germain y N un primo seguro ). N debe ser lo suficientemente grande como para que el cálculo de logaritmos discretos módulo N sea inviable.
• Toda la aritmética se realiza en el anillo de enteros módulo N ,${\displaystyle \scriptstyle \mathbb {Z} _{N}}$Esto significa que a continuación g ^x debe leerse como g ^x mod N
• g es un generador del grupo multiplicativo${\displaystyle \scriptstyle \mathbb {Z} _{N}^{*}}$.
• H () es una función hash ; por ejemplo, SHA-256.
• k es un parámetro derivado por ambas partes; en SRP-6, k = 3, mientras que en SRP-6a se deriva de N y g  : k = H ( N , g ). Se utiliza para evitar una suposición de 2 por 1 cuando un atacante activo suplanta la identidad del servidor. ^{[ 8 ] [ 9 ]}
• s es una sal .
• La "I" es un nombre de usuario identificativo.
• p es la contraseña del usuario.
• v es el verificador de contraseñas del host, v = g ^x donde como mínimo x = H ( s , p ). Como x solo se calcula en el cliente, es libre de elegir un algoritmo más robusto. Una implementación podría optar por usar x = H ( s | I | p ) sin afectar ningún paso requerido del host. El estándar RFC2945 define x = H ( s | H ( I | ":" | p ) ) . El uso de I dentro de x evita que un servidor malicioso pueda saber si dos usuarios comparten la misma contraseña .
• A y B son claves efímeras aleatorias de un solo uso del usuario y del host, respectivamente.
• | (barra vertical) denota concatenación.

Todas las demás variables se definen en función de estas.

Primero, para establecer una contraseña p con el servidor Steve, la cliente Carol elige un valor aleatorio s y calcula x = H ( s , p ), v = g ^x . Steve almacena v y s , indexados por I , como el verificador de contraseña y el valor aleatorio de Carol. Carol no debe compartir x con nadie y debe borrarlo de forma segura en este paso, ya que es equivalente a la contraseña en texto plano p . Este paso se completa antes de que el sistema se utilice como parte del registro de usuario con Steve. Cabe señalar que el valor aleatorio s se comparte e intercambia para negociar una clave de sesión posteriormente, por lo que el valor podría ser elegido por cualquiera de las partes, pero Carol lo hace para poder registrar I , s y v en una única solicitud de registro. La transmisión y autenticación de la solicitud de registro no se abordan en SRP.

Luego, para realizar una verificación de contraseña en una fecha posterior, se lleva a cabo el siguiente protocolo de intercambio:

1. Carol → Steve: genera un valor aleatorio a ; envía I y A = g ^a
2. Steve → Carol: genera un valor aleatorio b ; envía s y B = kv + g ^b
3. Ambos: u = H ( A , B )
4. Carol: S _Carol = ( B − kg ^x ) ^{( a + ux )} = ( kv + g ^b − kg ^x ) ^{( a + ux )} = ( kg ^x − kg ^x + g ^b ) ^{(a + ux)} = ( g ^b ) ^{( a + ux )}
5. Carol: K _Carol = H ( S _Carol )
6. Steve: S _Steve = ( Av ^u ) ^b = ( g ^a v ^u ) ^b = [ g ^a ( g ^x ) ^u ] ^b = ( g ^{a + ux} ) ^b = ( g ^b ) ^{(a + ux)}
7. Steve: K _Steve = H ( S _Steve ) = K _Carol

Ahora ambas partes tienen una clave de sesión segura y compartida K. Para completar la autenticación, deben demostrarse mutuamente que sus claves coinciden. Una posible forma es la siguiente:

1. Carol → Steve: M ₁ = H [ H ( N ) XOR H ( g ) | H ( I ) | s | A | B | K _Carol ] . Steve verifica M ₁ .
2. Steve → Carol: M ₂ = H ( A | M ₁ | K _Steve ) . Carol verifica M ₂ .

Este método requiere adivinar más información del estado compartido que la clave para lograr la suplantación de identidad. Si bien la mayor parte del estado adicional es público, se puede agregar información privada a los parámetros de la función hash, como la clave privada del servidor.

Alternativamente, en una prueba que solo utiliza contraseñas, se puede omitir el cálculo de K y probar la S compartida con:

1. Carol → Steve: M ₁ = H ( A | B | S _Carol ) . Steve verifica M ₁ .
2. Steve → Carol: M ₂ = H ( A | M ₁ | S _Steve ) . Carol verifica M ₂ .

Al utilizar SRP para negociar una clave compartida K que se usará inmediatamente después de la negociación, resulta tentador omitir los pasos de verificación M1 y M2 . El servidor rechazará la primera solicitud del cliente que no pueda descifrar. Sin embargo, esto puede ser peligroso, como se demuestra en la sección "Problemas de implementación" a _{continuación .}

Las dos partes también emplean las siguientes medidas de seguridad:

1. Carol abortará si recibe B = 0 (mod N ) o u = 0.
2. Steve abortará si recibe A (mod N ) = 0.
3. Carol debe mostrar primero su prueba de K (o S ). Si Steve detecta que la prueba de Carol es incorrecta, debe abortar sin mostrar su propia prueba de K (o S ).

""" Un ejemplo de autenticación SRPADVERTENCIA: No lo utilice para fines criptográficos reales, salvo para pruebas. ADVERTENCIA: El siguiente código carece de medidas de seguridad importantes. No comprueba que A, B y U no sean cero.basado en http://srp.stanford.edu/design.html """ import hashlib import random# Nota: str se convierte tal cual, str([1,2,3,4]) se convertirá en "[1,2,3,4]" def H ( * args ) -> int : """Una función hash unidireccional.""" a = ":" . join ( str ( a ) for a in args ) return int ( hashlib . sha256 ( a . encode ( "utf-8" )) . hexdigest (), 16 )def cryptrand ( n : int = 1024 ): return random . SystemRandom () . getrandbits ( n ) % N# Un primo seguro grande (N = 2q+1, donde q es primo) # Toda la aritmética se realiza módulo N # (generado usando "openssl dhparam -text 1024") N = """00:c0:37:c3:75:88:b4:32:98:87:e6:1c:2d:a3:32:  4b:1b:a4:b8:1a:63:f9:74:8f:ed:2d:8a:41:0c:2f: c2:  1b:12:32:f0:d3:bf:a0:24:27:6c:fd:88:44:81: 97  :aa:e4:86:a6:3b:fc:a7:b8:bf:77:54:df:b3:27:  c7:20:1f:6f:d1:7f:d7:fd:74:15:8b:d3:1c:e7:72:  c9:f5:f8:ab:58:45:48:a9:9a:75:9b:5a:2c:05:32:  16:2b:7b:62:18:e8:f1:42:bc:e2:c3:0d:77:84:68:  9a:48:3e:09:5e:70:16:18:43:79:13:a8:c3:9c:3d:  d0:d4:ca:3c:50:0b:88:5f:e3"""N = int ( "" . join ( N . split ()) . replace ( ":" , "" ), 16 ) g = 2 # Un generador módulo Nk = H ( N , g ) # Parámetro multiplicador (k=3 en SRP-6 heredado)F = '#0x' # Especificador de formatoprint ( "#. H, N, g y k son conocidos de antemano tanto por el cliente como por el servidor:" ) print ( f ' { H = } \n { N = :{ F }} \n { g = :{ F }} \n { k = :{ F }} ' )print ( " \n 0. El servidor almacena (I, s, v) en su base de datos de contraseñas" )# El servidor debe generar primero el verificador de contraseña I = "persona" # Nombre de usuario p = "password1234" # Contraseña s = cryptrand ( 64 ) # Sal para el usuario x = H ( s , I , p ) # Clave privada v = pow ( g , x , N ) # Verificador de contraseñaprint ( f ' { I = } \n { p = } \n { s = :{ F }} \n { x = :{ F }} \n { v = :{ F }} ' )# 0. El servidor almacena (I, s, v) en su base de datos de contraseñas # I = 'persona' # p = 'password1234' # s = 0x67bc8932cfd26a49 # x = 0x98a4bce8dde877762a90222f1a1161eba9248590a47eb83aa9e5bd7ecda5368d # v = 0xa7e2038e675d577ac0f318999cab67bba7ec2daf45d2d09f7911b1b78d2fc7f963cd0ac8f17851e0516f059e453672c3b70fcecf5f6843180b271a bdd01f552ccda7b24fe4719336409cbc1352f8517be651b8935cc0b74ff2819fa07a3f031537d4cfd9f8df7b788a5f2f88e1cd4106b35c38b3d7205a# <demo> --- detener ---print ( " \n 1. El cliente envía el nombre de usuario I y el valor público efímero A al servidor" ) a = cryptrand () A = pow ( g , a , N ) print ( f " { I = } \n { A = :{ F }} " ) # cliente->servidor (I, A)# 1. El cliente envía el nombre de usuario I y el valor público efímero A al servidor # I = 'persona' # A = 0x678556a7e76581e051af656e8cee57ae46df43f1fce790f7750a3ec5308a85da4ec4051e5cb74d3e463685ee975a2747cf49035be67c931b56e793f23ea3524af8909dcfbc8675d872361025bf884778587ac49454a57c53a011ac2be2839bfb51bf7847a49a483aba870dc7a8b467a81cec91b8ae7813# <demo> --- detener ---print ( " \n 2. El servidor envía la sal del usuario s y el valor efímero público B al cliente" ) b = cryptrand () B = ( k * v + pow ( g , b , N )) % N print ( f " { s = :{ F }} \n { B = :{ F }} " ) # servidor->cliente (s, B)# 2. El servidor envía la sal del usuario s y el valor efímero público B al cliente # s = 0x67bc8932cfd26a49 # B = 0xb615a0a5ea6abf138077bbd869f6a8da37dfc0b7e06a9f5fac5c1e4109c6302cb3e94dcc2cc76da7b3d87d7e9b68a1db998ab239cfde609f3f7a1e ce4a491ce3d9a665c20cf4e4f06730daaa8f52ed61e45bbb67cdc337bf648027ffa7f0f215d5ebe43f9f51832518f1142266aae0dfa960e0082b5154# <demo> --- detener ---print ( " \n 3. El cliente y el servidor calculan el parámetro de codificación aleatoria" ) u = H ( A , B ) # Parámetro de codificación aleatoria print ( f " { u = :{ F }} " )# 3. El cliente y el servidor calculan el parámetro de codificación aleatoria # u = 0x796b07e354c04f672af8b76a46560655086355a9bbce11361f01b45d991c0c52# <demo> --- detener ---print ( " \n 4. el cliente calcula la clave de sesión" ) x = H ( s , I , p ) S_c = pow ( B - k * pow ( g , x , N ), a + u * x , N ) K_c = H ( S_c ) print ( f " { S_c = :{ F }} \n { K_c = :{ F }} " )# 4. El cliente calcula la clave de sesión # S_c = 0x699170aff6e9f08ed09a1dff432bf0605b8bcba05aadcaeea665757d06dbda4348e211d16c10ef4678585bcb2809a83c62b6c19d97901274ddafd4075f90604c06baf036af587af8540342b47867eaa22b9ca5e35ac14c8e85a0c4e623bd855828dffd513cea4d829c407137a0dd81ab4cde8a904c45cc # K_c = 0x43f8df6e1d2ba762948c8316db5bf03a7af49391742f5f51029630711c1671e# <demo> --- detener ---print ( " \n 5. El servidor calcula la clave de sesión" ) S_s = pow ( A * pow ( v , u , N ), b , N ) K_s = H ( S_s ) print ( f " { S_s = :{ F }} \n { K_s = :{ F }} " )# 5. El servidor calcula la clave de sesión # S_s = 0x699170aff6e9f08ed09a1dff432bf0605b8bcba05aadcaeea665757d06dbda4348e211d16c10ef4678585bcb2809a83c62b6c19d97901274ddafd4075f90604c06baf036af587af8540342b47867eaa22b9ca5e35ac14c8e85a0c4e623bd855828dffd513cea4d829c407137a0dd81ab4cde8a904c45cc # K_s = 0x43f8df6e1d2ba762948c8316db5bf03a7af49391742f5f51029630711c1671e# <demo> --- detener ---print ( " \n 6. El cliente envía la prueba de la clave de sesión al servidor" ) M_c = H ( H ( N ) ^ H ( g ), H ( I ), s , A , B , K_c ) print ( f " { M_c = :{ F }} " ) # cliente->servidor (M_c) ; el servidor verifica M_c# 6. El cliente envía la prueba de la clave de sesión al servidor # M_c = 0x75500df4ea36e06406ac1f8a8241429b8e90a8cba3adda3405c07f19ea3101e8# <demo> --- detener ---print ( " \n 7. El servidor envía la prueba de la clave de sesión al cliente" ) M_s = H ( A , M_c , K_s ) print ( f " { M_s = :{ F }} " ) # servidor->cliente (M_s) ; ​​el cliente verifica M_s# 7. El servidor envía la prueba de la clave de sesión al cliente # M_s = 0x182ed24d1ad2fb55d2268c46b42435d1ef02e0fc49f647c03dab8b2a48b0bd3d

• Variables SRP-6: Una biblioteca Java de primitivas criptográficas necesarias para implementar el protocolo SRP-6.
• OpenSSL versión 1.0.1 o posterior.
• Botan (la biblioteca criptográfica de C++) contiene una implementación de SRP-6a.
• TLS-SRP es un conjunto de algoritmos de cifrado para la seguridad de la capa de transporte que utiliza SRP.
• srp-client Implementación de SRP-6a en JavaScript (compatible con RFC 5054), código abierto, con licencia de Mozilla Public License (MPL).
• La biblioteca criptográfica de JavaScript incluye una implementación en JavaScript del protocolo SRP, de código abierto y con licencia BSD .
• Gnu Crypto proporciona una implementación en Java con licencia GNU General Public License con la "excepción de biblioteca", que permite su uso como biblioteca junto con software privativo.
• La Legión del Castillo Hinchable proporciona implementaciones en Java y C# bajo la Licencia MIT .
• Nimbus SRP es una biblioteca Java que proporciona un generador de verificadores y sesiones tanto del lado del cliente como del servidor. Incluye interfaces para claves de contraseña personalizadas y rutinas de mensajes de evidencia para el cliente y el servidor. No tiene dependencias externas. Se publica bajo la licencia Apache 2.0 .
• srplibcpp es una implementación en C++ basada en MIRACL .
• DragonSRP es una implementación modular en C++ que actualmente funciona con OpenSSL .
• Json2Ldap proporciona autenticación SRP-6a a servidores de directorio LDAP .
• Implementación de csrp SRP-6a en C.
• Implementación de Crypt-SRP SRP-6a en Perl .
• Implementación de pysrp SRP-6a en Python (compatible con csrp ).
• Implementación de py3srp SRP-6a en Python3 puro .
• srptools Herramientas para implementar la autenticación de contraseña remota segura (SRP) en Python . Bibliotecas compatibles verificadas .
• El sistema de cuentas del framework web Meteor implementa el protocolo SRP para la autenticación mediante contraseña.
• Implementación de SRP-6a en Ruby mediante srp-rb .
• falkmueller demo Implementación SRP-6a del diseño del protocolo Stanford SRP en JavaScript y PHP bajo la licencia MIT .
• srp-6a-demo Implementación de SRP-6a en PHP y JavaScript .
• thinbus-srp-js Implementación de SRP-6a en JavaScript . Incluye clases Java compatibles que utilizan Nimbus SRP. Archivado el 22/02/2014 en Wayback Machine. Una aplicación de demostración que utiliza Spring Security . También hay una aplicación de demostración que realiza la autenticación en un servidor PHP . Publicado bajo la licencia Apache .
• La biblioteca criptográfica JavaScript de Stanford (SJCL) implementa el protocolo SRP para el intercambio de claves.
• node-srp es una implementación de SRP (Protección de Responsabilidad Única) para cliente y servidor JavaScript (node.js).
• Implementación de SRP6 para C# y Java en C# y Java.
• ALOSRPAuth es una implementación en Objective-C de SRP-6a.
• go-srp es una implementación en Go de SRP-6a.
• tssrp6a es una implementación de SRP-6a en TypeScript.
• La biblioteca Java IceNet Cryptography permite desarrollar aplicaciones Spring Boot basadas en criptografía. Implementa SRP-6a. Bajo licencia Apache .
• SRP-6a en la implementación .NET de SRP-6a
• Apple HomeKit utiliza SRP al emparejarse con accesorios y dispositivos domésticos "inteligentes".
• Autenticación de Proton Mail para cifrado de correo electrónico
• SRP es una implementación en Go del protocolo SRP, que se utiliza para autenticar usuarios en Posterity .

El proyecto SRP se inició en 1997. ^{[ 11 ]} Dos enfoques diferentes para corregir una vulnerabilidad de seguridad en SRP-1 dieron como resultado SRP-2 y SRP-3. ^{[ 12 ]} SRP-3 se publicó por primera vez en 1998 en una conferencia. ^{[ 13 ]} RFC 2945, que describe SRP-3 con SHA1, se publicó en 2000. ^{[ 14 ]} SRP-6, que corrige los ataques de adivinación "dos por uno" y de ordenación de mensajes, se publicó en 2002. ^{[ 8 ]} SRP-6a apareció en la "libsrp" oficial en la versión 2.1.0, de 2005. ^{[ 15 ]} SRP-6a se encuentra en los estándares como:

• ISO/IEC 11770-4:2006 "Mecanismo de Acuerdo Clave 2" (llama al método "SRP-6", pero tiene el cálculo k de 6a)
• RFC 5054 TLS-SRP de 2007 (de nuevo denominado "SRP-6", pero corregido en la errata ^{[ 16 ]} )
• IEEE Std 1363.2-2008 "DLAPKAS-SRP6" (de nuevo denominado "SRP-6") ^{[ 17 ]}

IEEE 1363.2 también incluye una descripción de "SRP5", una variante que reemplaza el logaritmo discreto con una curva elíptica aportada por Yongge Wang en 2001. ^{[ 18 ]} También describe SRP-3 tal como se encuentra en RFC 2945.

• autenticación de desafío-respuesta
• Acuerdo de clave autenticada mediante contraseña
• Mecanismo de autenticación de respuesta de desafío con sal (SCRAM)
• Intercambio de claves exponencial de contraseña simple
• A prueba de contraseñas de conocimiento cero

• Sitio web oficial
• Licencia SRP : software libre similar a BSD.
• US6539479 - Patente SRP (Caducó el 12 de mayo de 2015 por falta de pago de las tasas de mantenimiento (según Google Patents). Originalmente, su vencimiento estaba previsto para julio de 2018).