Autenticación de contraseña

Autenticacion de contraseña

Autenticacion de contraseña : Multi-millones de consejos para hacer su vida mas facil.

autenticacion de Contraseña se utiliza en muchos sistemas de autenticacion de la identidad de uno o ambos compañeros de una conexion. Este documento le ayudara a diseñar contraseña mas segura esquemas de autenticacion utilizando tecnicas de criptografia simetrica.


Autenticacion de Contraseña usando Simetrica Tecnicas

@page { size: 21cm 29.7 cm margin: 2cm }
P { margin-bottom: 0.21 cm }
H1 { margin-bottom: 0.21 cm }
H1.western { font-family: 'Arial', sans-serif font-size: 16 pt }
H1.cjk { font-family: 'Lucida Sans Unicode' font-size: 16 pt }
H1.ctl { font-family: 'Tahoma' font-size: 16 pt }
H2 { margin-bottom: 0.21 cm }
H2.western { font-family: 'Arial', sans-serif font-size: 14pt font-style: italic }
H2.cjk { font-size: 14pt font-style: italic }
H2.ctl { font-size: 14pt font-style: italic }
H3 { margin-bottom: 0.21 cm }
H3.western { font-family: 'Arial', sans-serif }
H4 { margin-bottom: 0.21 cm }
H4.western { font-family: 'Arial', sans-serif font-size: 11pt font-style: italic }
H4.cjk { font-size: 11pt font-style: italic }
H4.ctl { font-size: 11pt font-style: italic }
& >

Contraseña
Autenticacion

por Henrick Hellström,
StreamSec, 2004. Todos los derechos reservados.

autenticacion de Contraseña se utiliza en muchos sistemas de autenticacion de la identidad de uno o ambos compañeros de una conexion. La mayoria de los esquemas que se utilizan hoy en dia son extremadamente inseguro, incluso si se emplean algoritmos de cifrado, tales como las funciones de hash y funciones de cifrado. Este documento le ayudara a detectar algunas deficiencias comunes y mas el diseño de autenticacion de contraseña segura esquemas utilizando tecnicas de criptografia simetrica.
Consejo General

Cada contraseña de autenticacion basada en el sistema es, sin excepciones, vulnerable a ciertos ataques si el uso de las contraseñas debiles. Por el contrario, el uso de una contraseña segura, o mas bien la frase, no te hara ningun bien si usted lo usa durante debiles o seriamente comprometida sistemas de autenticacion. Algunos consejos generales son:

• el Uso de contraseñas y frases de contraseña que pueda recordar. Tener que escribir su contraseña, o guardar en un archivo en algun lugar, rara vez es una buena cosa.
  

• el Uso pase largo frases con varias frases en lugar de a corto ocultar contraseñas con caracteres no alfabeticos. Recordar una contraseña segura con 20 letras digitos y caracteres especiales es para la mayoria de la gente mucho mas dificil de recordar 128 de la carta de la frase que consta solo de inteligiblefrases.
  

• el Uso de la misma favorito frase de contraseña para cada servicio que usted sabe emplea un esquema de autenticacion de contraseña segura. Tener que recordar una multitud de contraseñas para diferentes servicios es mala. Usted debe usar su cerebro para algo mas productivo.
  

• al mismo tiempo, usted DEBE recordar que la mayoria de los servicios por desgracia, no se emplean esquemas de autenticacion de contraseña segura.Si utiliza el mismo frase de para bothservice Un servicio y B, su acceso a servicio podria verse en peligro si el servicio de B es o se pone en peligro. Si tanto habia utilizado los servicios de autenticacion de contraseña segura esquemas de esto no habria sido un motivo de preocupacion.
  

El Problema

Alice quiere demostrar a alguien que ella cree ser el Bob que ella es Alice. Alice quiere hacerlo sin revelar ninguna informacion secreta a Eva (que es el espionaje en la conversacion) o Mallory (que tiene una tendencia a suplantar a Bob y Alice con el fin de engañar a revelar sus secretos). Ademas, Alice quiere utilizar el mismo metodo de autenticacion para probar su identidad a Demandar, y ella no quiere poner su propio, de Bob o de Sue en riesgo la seguridad en caso de Bob o de la demanda se convierte en peligro.
Primitivas Criptograficas
las Funciones de Hash

Un sistema de encriptacion Secure Hash Funcion de transformar la entrada de cualquier longitud para un tamaño fijo de codigo de salida, conocido como el Compendio de la entrada. La funcion hash tiene las siguientes propiedades:

1. es computacionalmente imposible encontrar cualquier dato que hashes para un determinado arbitraria de digerir. En otras palabras, una Funcion de Hash Criptografica no pueden ser facilmente invertida pero es computacionalmente. Esta propiedad es tambien conocido como Primario Preimagen Resistencia>.
   

2. es computacionalmente imposible encontrar dos diferentes entradas que hash para el mismo valor de sintesis. Una Funcion de Hash Criptografica es Libre de Colision. Esta propiedad es tambien conocido como Secundario la Preimagen de Resistencia.
   

Como consecuencia de estas dos propiedades de una funcion de hash puede ser utilizado para los siguientes fines:

(*) Sea T_A y T_A dos entradas y dejar D y D_A ser la correspondiente a digerir los valores de estas dos entradas. Si D = D_A
es seguro para deducir que T = T_A.
StreamSec Uso de las Herramientas de

el siguiente codigo calcula El resumen SHA-1 de los contenidos de la AnsiString aText. El resumen SHA-1 es un 20 cadena de caracteres, posiblemente, que consiste en no imprimibles de caracteres de 8 bits.
usa
stSecUtils, stSHA1
...
lDigest := DigestString(haSHA1,aText)
Ejemplo 1 (Justo, pero no uso seguro)

Alice envia el resumen D de su contraseña secreta T a Bob. Bob busca de Alice en su usuario de la tabla de datos, obtiene el valor almacenado D ' y verifica que D = D'. El valor real de T no es revelado durante este proceess.
Ejemplo 2 (Ataque)

Eva aprehende el valor D enviado por Alicia en el Ejemplo 1. Eva se conecta a Bob y envia D. Bob es engañado en la creencia de que Eva es Alice. Esto se conoce como un Ataque de Reproduccion.
Ejemplo 3 (Ataque)

Harry se registra un gran numero de personalidades con Bob servicio. Mas tarde, Harry es capaz de robar Bob usuario del objeto datatable. Harry realiza una consulta en la tabla de datos y descubre que el valor de D para Alice es identico al valor D_A para uno de Harry falsas personalidades. Harry es capaz de inferir que Alice contraseña secreta T es identico a la contraseña T_A para su correspondiente falsa personalidad.
Ejemplo 4 (Limitacion)

no es raro que los distribuidores de software de codigo Abierto son la publicacion de el codigo MD5 de cada archivo junto con el propio archivo. Este esquema proporciona muy poco de seguridad, debido a las propiedades generales de las funciones de hash. Si se le da un par de _A,D> usted es capaz de verificar que D es en realidad un valido compendio de T, pero no hay ninguna manera de verificar que T
y D
no ha sido reemplazado por alguien que no sea el distribuidor. Nadie
es capaz de generar una valida MD5 de cualquier cosa.
Llave de las Funciones de Hash

Una llave de una funcion hash es una funcion hash con la propiedad adicional de que una valida digerir (tambien conocido como un Codigo de Autenticacion de Mensaje o MAC) solo puede ser calculado por alguien que sabe especificos de la clave secreta. El tipo mas comun de la Llave, la Funcion de Hash es HMAC. La funcion HMAC funciona con todos los MD4 tipo de funciones de hash, como MD5 y el RipeMD y SHA la familia de funciones de hash, y opera por la mezcla de la entrada dos veces y se mezcla el material de clave con diferentes rellenos cada vez.

Llave de las Funciones de Hash uso de claves simetricas, lo que significa que tanto la
remitente y el destinatario de un mensaje debe establecer la misma clave.

(*) sea T_A y T_A dos entradas, K y K_A dos llaves y que M y M_A ser la respectiva MAC valores de estas dos entradas. Si M = M_A a continuacion, es seguro para inferir que tanto T = T_A y K = K_B.
StreamSec Uso de las Herramientas de

el siguiente codigo calcula El HMAC-SHA-1 el valor de los contenidos de la AnsiString aText. El MAC es un alongitud cadena de caracteres (en la mayoria de la misma longitud que el compendio de la longitud de la base, la funcion de hash), posiblemente, que consiste en no imprimibles de caracteres de 8 bits.
usa
stSecUtils, stSHA1
...
lMAC := HMACString(haSHA1,aKey,alongitud,aText)
Ejemplo 5 (Justo, pero no uso seguro)

Alice envia el MAC M_KA de la cadena de 'Alicia' y su contraseña secreta T como clave para Bob. Bob busca de Alice en su usuario de la tabla de datos, obtiene el valor almacenado M_KA ' y verifica que M_KA = M_KA'. El valor real de T no es revelado durante este proceess.
Ejemplo 6 (Ataque)

Eva aprehende el valor de M_KA enviado por Alicia en el Ejemplo 1. Eva se conecta a Bob y envia M_KA. Bob es engañado en la creencia de que Eva es Alice.
Ejemplo 7 (Fallido Ataque)

Harry se registra un gran numero de personalidades con Bob servicio. Mas tarde, Harry es capaz de robar Bob usuario del objeto datatable. Harry realiza una consulta en la tabla de datos, pero es incapaz de encontrar cualquier MAC valores que son identicos, ya que el HMAC es sin colisiones y Bob aplica la regla de que los nombres de usuario debe ser unico.
en el Ejemplo 8 (Limitacion)

el Uso de una Llave, la Funcion de Hash para demostrar la integridad y autenticidad de los archivos publicos rara vez es una opcion.

en primer lugar, un HMAC utiliza una clave simetrica. Esto significa que el remitente y el destinatario son capaces de generar una MAC valida de cualquier entrada de texto. Si Alice, Bob y Carol, todos comparten el mismo secreto clave HMAC, no hay manera de que Alice para saber si una MAC dada de valor fue calculado por Bob o por Carol.

en Segundo lugar, una llave, la funcion de hash no provee beneficios de la seguridad a traves de una regular (unkeyed), la funcion de hash a menos que la clave se mantiene en secreto. Si usted publicar un par _A,M_KA> nadie que no conozca la clave K sera capaz de verificar que M_KA es en realidad una MAC valida de T.
Otros Conceptos
la Sal y el Nonce

La distincion entre una Sal y un Nonce es flotante, pero se menciona aqui, para mayor claridad:

• Ambos se generan en una forma que esta diseñado para hacer unico, dentro de un contexto, por ejemplo, por un Generador de numeros Aleatorios Criptograficamente Segura, tales como la Milenrama.
  

• Ambos se utilizan de tal manera que no tiene que ser mantenido en secreto, pero puede ser transmitida a traves de los desprotegidos canales.
  

• Ambos son normalmente mezclado con material secreto durante algun tipo de operacion hash.
  

• UNA Sal que se utiliza normalmente para la generacion de un Comprobador de valor que consiste en el hash de la Sal y la Contraseña. La Sal y el Verificador se almacenan juntos en el receptor (servidor) para el tiempo de vida de la contraseña. Si no aleatoria de la Sal podria ser la concatenacion del nombre de usuario del destinatario y el remitente nombre de usuario.
  

• UNA sal es mas, precisamente, normalmente utilizados para la fabricacion de los hash de las contraseñas almacenadas en el lado del servidor usuario de tablas de datos unica. Conferir el Ejemplo 4 Ejemplo y 8 anteriores.
  

• UN Nonce es tipicamente usado solo una vez para una sola sesion apreton de manos o para un unico mensaje. Si no es generado al azar podria ser una marca de tiempo o un auto incrementa persistente contador. Nonces se utilizan normalmente en Desafio-Respuesta protocolos frustrar los ataques del tipo descrito en el Ejemplo 2 y Ejemplo 6.
  

Reto-Protocolos de Respuesta

Una forma comun de evitar algunos de los ataques descritos en las secciones anteriores es el uso de Desafio-Respuesta de los Protocolos. Estos protocolos de mezcla al azar en el material con las contraseñas. Bien hecho esto hace que sea imposible generar valido protocolo de mensajes sin la informacion secreta que solo los legitimos partes se supone que tienen.

Estos protocolos unica salida binaria Si o No a la pregunta: ¿Fueron los entrantes protocolo de mensajes de autentica? Mas elaborado protocolos ademas de la salida de una Clave de Sesion que se utiliza para la proteccion de la confidencialidad y la integridad de los mensajes de los siguientes mensajes masivos. Los beneficios de la seguridad de la utilizacion de estos protocolos no debe ser subestimada, ya que implica que la confidencialidad y la integridad de la mayor parte del contenido esta estrechamente vinculado a la Entidad de Autenticacion establecidos durante la fase de autenticacion del protocolo.

de Desafio-Respuesta protocolos son tradicionalmente diseñado Pase de Dos o Tres pasos. Dos-Pase de Desafio-Respuesta protocolos se utilizan para la autenticacion del cliente al servidor, pero no en el servidor al cliente. En esta seccion se describen dos de Tres pasos de los protocolos que se autenticar el cliente y el servidor para cada uno de los otros.
el Protocolo de #1

Este protocolo esta diseñado para situaciones donde la velocidad de la
la red es el mayor cuello de botella.
los Preparativos:

Cada cliente de la entidad Carol se registra a si misma con el servidor de la entidad
Sue. Ya sea Carol Sue o genera los siguientes valores:

Salt[Carol] := HMACString(haSHA1,de nombre real[Carol],20,de nombre real[Sue])

Verificador[Carol] := HMACString(haSHA1,Sal[Carol],20,Contraseña[Carol])

Sue registros de nombre real[Carol] y Verificador[Carol].

• no es importante para el funcionamiento del protocolo real si Carol Sue o genera el Verificador[Carol] el valor, ya que Sue no uso Contraseña[Carol] en cualquier momento durante el protocolo real. Sin embargo, es importante que los valores que se envian entre Carol y Demandar durante la fase de registro estan garantizados para ser confidencial y autentica. Ademas, Carol debe enviar el Comprobador de[Carol] en lugar de la Contraseña[Carol] si ella tiene la intencion de volver a usar la misma contraseña para otros fines. Es computacionalmente imposible derivar Contraseña[Carol] de Verificador[Carol].
  

• El valor de la Sal[Carol] debe ser unico. En particular, de nombre real[Sue] debe ser ajustado a cualquier informacion que pueda identificar plenamente el particular servicio denotado 'Sue', tales como un total de URI incluidos el protocolo, el nombre de host y la ruta de acceso, posiblemente mezclado con la informacion estatica de Sue Servidor del mensaje Hello. Alternativamente, la Sal[Carol] podria ser generados al azar, sino que requeriria que la Sal[Carol] se almacena por Sue y se transmite de nuevo a Carol durante el protocolo. Se supone que si la Sal[Carol] se genera de acuerdo a la definicion anterior, tanto Carol y Demandar de forma independiente puede regenerar el valor en cualquier momento posterior.
  

• Sue debe mantener el Verificador[Carol] valor confidencial. Por lo general se almacenan en una tabla de datos, y si este datatable se ve comprometida de cada usuario willhave para generar nuevo Comprobador de valores. Es importante tonote que es imposible generar nuevo Comprobador de valores, si ninguno de los valores de nombre real[Sue], nombre real de[Carol] ni Contraseña[Carol] es cambiado, desde el Comprobador de[Carol] es una funcion determinista de estos valores. Sue debe por consiguiente cambio de nombre real[Sue] si las funciones descritas anteriormente se utilizan y el usuario datatable se ve comprometida. Una alternativa es usar generadas aleatoriamente los valores de Sal.
  

Pasos y Mensajes de:

1. Sue genera al azar nonce Nonce_S.
   

2. Sue -> Carol:Nonce_S
   

3. Carol genera al azar Nonce_C.
   

4. Carol calcula el Comprobador de[Carol] como se describio anteriormente.
   

5. Carol calcula Temp1 := HMACString(haSHA1,el Verificador[Carol],20,Nonce_S)
   

6. Carol calcula Response_C := HMACString(haSHA1,Temp1,20,Nonce_C)
   

7. Carol -> Sue: de nombre real[Carol], Nonce_C, Response_C
   

8. Sue busca de nombre real[Carol] en el usuario de la tabla de datos y obtiene el Comprobador de[Carol].
   

9. Sue calcula Response_C como se describio anteriormente y lo compara con el valor recibido de Carol. Si los valores no coinciden Sue se anula, lo que resulta en el protocolo de salida 'No'.
   

10. Sue calcula Temp2 := HMACString(haSHA1,el Verificador[Carol],20,Nonce_C)
    

11. Sue calcula Response_S := HMACString(haSHA1,Temp2,20,Nonce_S)
    

12. Sue -> Carol: Response_S
    

13. Carol calcula Response_S como se describio anteriormente y lo compara con el valor recibido de Sue. Si los valores no coinciden con Carol se anula, lo que resulta en el protocolo de salida 'No'.
    

14. 'Salida de Si'.
    

Protocolo de #2

Este protocolo es una variacion del Protocolo #1, con la diferencia de que la Sal[Carol] el valor es generado aleatoriamente y se almacena en el Sue de usuario del objeto datatable. Las implicaciones de esto ya han sido discutidos.
Pasos y Mensajes de:

1. Carol genera al azar Nonce_C.
   

2. Carol -> Sue: de nombre real[Carol], Nonce_C
   

3. Sue busca de nombre real[Carol] en el usuario de la tabla de datos y obtiene la Sal[Carol], el Verificador[Carol].
   

4. Sue genera un valor aleatorio Reto
   

5. Sue calcula Nonce_S := HMACString(haSHA1,de Desafio,de 20 años,de nombre real[Sue])
   

6. Sue calcula Temp1 := HMACString(haSHA1,el Verificador[Carol],20,Nonce_C)
   

7. Sue calcula Response_S := HMACString(haSHA1,Temp1,Nonce_S)
   

8. Sue -> Carol:Desafio, la Sal[Carol], Response_S
   

9. Carol calcula el Comprobador de[Carol] := HMACString(haSHA1,Sal[Carol],20,Contraseña[Carol])
   

10. Carol calcula Nonce_S como se describio anteriormente.
    

11. Carol calcula Response_S como se describio anteriormente y lo compara con el valor recibido de Sue. Si los valores no coinciden con Carol se anula, lo que resulta en el protocolo de salida 'No'.
    

12. Carol calcula Temp2 := HMACString(haSHA1,el Verificador[Carol],20,Nonce_S)
    

13. Carol calcula Response_C := HMACString(haSHA1,Temp2,20,Nonce_C)
    

14. Carol -> Sue: Response_C
    

15. Sue calcula Response_C como se describio anteriormente y lo compara con el valor recibido de Carol. Si los valores no coinciden Sue se anula, lo que resulta en el protocolo de salida 'No'.
    

16. 'Salida de Si'.
    

Otras Consideraciones

Una caracteristica comun de ambos Protocolo #1 y Protocolo #2 es que el uso exclusivo de cifrado simetrico primitivas (HMAC) hace que el usuario datatable extremadamente sensibles a comprometer. Los protocolos de solo proporcionar a la entidad de autenticacion si Sue se las arregla para mantener al usuario datatable tanto confidencial y autentica. El uso de una Sal en el calculo de la Comprobador de valores de se proteger la confidencialidad de las contraseñas, pero no evitar que un atacante que obtiene el Comprobador de valores de la simulacion de los pasos y los mensajes de Carol en cualquiera de Protocolo #1 o Protocolo #2. Si dicha proteccion se requiere un protocolo diferente que emplea Asimetrica de cifrado Primitivas, tales como el programa de alineacion estrategica, debe ser utilizado.

Otra consideracion es que tanto el Protocolo de #1 y Protocolo #2 solo la salida de un binario Si o No, lo que significa que la salida del protocolo no esta necesariamente vinculado a la confidencialidad o la integridad de la mayor parte del contenido de la sesion. En particular, cabe señalar que la Nonces que se utilizan como parte de los protocolos de proteger contra los Ataques de Reproduccion de la clase descrita en el Ejemplo 2 y Ejemplo 6, pero no van a proteger contra el Hombre-En-El-Medio de los ataques:
en el Ejemplo 9 (Ataque)

Este es un ejemplo de como un Hombre-En-El-Medio (Mallory) puede atacar Protocolo #2. Existen tambien un ataque contra el Protocolo #1.

1. Mallory trucos de Carol en la creencia de que Mallory es Sue. La dificultad de este engaños depende de un gran numero de factores, tales como la integridad de la red y la posible implementacion de defectos en el mecanismo de Carol utiliza para asociar nombre real[Sue] con un servicio en particular.
   

2. Carol -> Mallory: de nombre real[Carol], Nonce_C
   

3. Mallory -> Sue: de nombre real[Carol], Nonce_C
   

4. Sue -> Mallory:Desafio, la Sal[Carol], Response_S
   

5. Mallory -> Carol:Desafio, la Sal[Carol], Response_S
   

6. Carol -> Mallory: Response_C
   

7. Mallory -> Sue:Response_C
   

8. Sue salidas 'True'. Carol salidas 'de Verdad'.
   

El ultimo paso podria implicar que Carol piensa que ella se ha verificado que Mallory es Sue, o que Sue piensa que ella se ha verificado que Mallory es Carol. Es importante tener en cuenta que ni el Protocolo #1 ni el Protocolo de #2 dara a tales garantias. Se solo probar que los mensajes que se origino a partir de la entidad autenticada, pero no para que esta entidad es necesariamente identica a la de otros compañeros. Tambien tenga en cuenta que esto no es necesariamente una mala cosa (creo Proxy, de Nivel Medio y Equilibrio de Carga), pero que las implicaciones de seguridad a menudo hacen que sea extremadamente dificil el uso de estos protocolos adecuadamente.
Asimetrica de Desafio-Respuesta Protocolos

Esta seccion, se describe un protocolo que se onlined despues de la
Remoto Seguro, protocolo de autenticacion de Contraseña (SRP) por Thomas Wu de la Universidad de Stanford. El protocolo es relativamente complejo, pero ofrece una gama de servicios de seguridad que lo hace interesante para invertir el tiempo en la aplicacion. Citado en el documento original:

• permitir a Un atacante ni la contraseña del usuario ni la contraseña del host de archivos no se puede montar un ataque de diccionario de las contraseñas. La autenticacion mutua se logra en este escenario.
  

• Un atacante que capta el host del archivo de contraseña directamente no se puede comprometer de usuario para autenticacion de host y tener acceso al host sin necesidad de un costoso busqueda de diccionario.
  

• Un atacante que compromete el host no obtener la contraseña de un legitimo intento de autenticacion.
  

• Un atacante que captura la clave de sesion no se puede utilizar para montar un ataque de diccionario de las contraseñas.
  

• Un atacante que captura la contraseña del usuario la puede utilizar para comprometer las claves de sesion sesiones pasadas.
  

Ejemplo

a Continuacion es el lado del cliente SRP codigo, tomado de la SRP demo en las Variantes de la carpeta
var
lA, lB, lX, lV, lS: Variante
lAPriv: Variante
lSalt: cadena
lc: Cadenadeoctetos
lM1, lM2: cadena
begin
Conectar
// una,Una es el cliente clave efimera, Diffie-Hellman estilo
lAPriv := RandomPrivateKey
lA := VarMPIntegerExpMod(2,lAPriv,P)
// C -> S: de usuario, Un
Send('usuario',edtUsername.De texto)
Send( ' ',lA)
// S - C: sal, B
lSalt := Leer('sal')
lB := Leer('B')
// B es el servidor publico clave efimera, Diffie-Hellman estilo, mixto
// con el cliente V valor que se almacena en el servidor del usuario datatable
// junto con la sal y el usuario.
// El cliente DEBE cancelar si B = 0
si (lB mod P) = 0 entonces begin
de Error('error de autorizacion')
fin
// X es el cliente a largo plazo de la clave privada y se deriva de la contraseña
lX := HashPassword(lSalt,edtUsername.Texto,edtPassword.De texto)
// V es el cliente 'verificador' o a largo plazo de clave publica.
// se utiliza en el programa de alineacion estrategica de protocolo, de tal manera que esta no puede ser obtenida por
// un atacante desde el protocolo de mensajes. Esto hace que un ataque de diccionario
// en contra de la contraseña de usuario tan dificil como resolver el Discreto Registro de Problema
lV := VarMPIntegerExpMod(2,lX,P)
// El 'real' servidor publico efimero clave es B-V. planteadas por el cliente
// a una potencia (u*X) que tambien oculta el valor de X detras de la dureza de
// el Discreto Registro de Problema. S es el secreto compartido de salida de esta operacion
lS := VarMPIntegerExpMod(lB-lV,
lAPriv lX * CalculateU(lB),
P)
// K es la clave compartida que se deriva de el secreto compartido S
lc := SHA_Interleave(lS)
// M1 es el cliente termine el mensaje. Solo puede ser calculado por el cliente
// y por el servidor. El proposito de este mensaje es para probar que el cliente
// derivados el mismo valor de K como el servidor, y por lo tanto, que el cliente sepa
// la contraseña
lm 1 := FinishHashClient(edtUserName.Texto
lSalt,
lA,
lB,
lc)
// C -> S: M1
Send('M1',lM1)
// S -> C: M2
lM2 := Leer('M2')
// M2 es el servidor terminado mensaje. Solo puede ser calculado por el servidor
// y por el cliente. El proposito de este mensaje es para probar que el servidor
// derivados el mismo valor de K como el cliente, y de ahi que el servidor sabe que
// V comprobador de valor
si lM2 <> FinishHashServer(lA,lm 1,lc) begin
de Error('error de autorizacion')
persona
SetKey(lc)