Authentification par mot de passe

Authentification par mot de passe

Authentification par mot de passe : Plusieurs milliers de conseils pour vous faciliter la vie.

le Mot de passe d'authentification est utilise dans de nombreux systemes pour l'authentification de l'identite de l'un ou les deux pairs d'une connexion. Ce livre va vous aider a concevoir plusieurs schemas d'authentification par mot de passe securise a l'aide de chiffrement symetrique techniques.


Mot de passe d'Authentification a l'aide Symetrique Techniques

@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: 16pt }
H1.cjk { font-family: 'Lucida Sans Unicode' font-size: 16pt }
H1.ctl { font-family: 'Tahoma' font-size: 16pt }
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 }
& >

Mot de passe
Authentification

par Henrick Hellström,
StreamSec, 2004. Tous droits reserves.

Mot de passe d'authentification est utilise dans de nombreux systemes pour l'authentification de l'identite de l'un ou les deux pairs d'une connexion. La plupart des systemes qui sont utilises aujourd'hui sont trivialement en insecurite, meme s'ils emploient des algorithmes cryptographiques telles que les fonctions de hachage et de chiffrement. Ce document vous aidera a reperer certains points faibles communs et la conception de plus de mot de passe securise schemas d'authentification a l'aide des techniques de cryptographie symetrique.
des Conseils Generaux

Chaque mot de passe de l'authentification basee sur les systeme est, sans exceptions, vulnerables a certaines attaques si vous utilisez des mots de passe faibles. A l'inverse, a l'aide d'un mot de passe fort, ou plutot des mots de passe, ne sera pas vous faire du bien si vous l'utilisez pour la faiblesse ou gravement compromis les systemes d'authentification. Certains conseils generaux sont les suivants:

• Utilisez des mots de passe et mots de passe dont vous vous souviendrez. Avoir a ecrire votre mot de passe, ou le stocker dans un fichier quelque part, est rarement une bonne chose.
  

• Utilisez des mots de passe avec plusieurs phrases plutot que sur le court obscur des mots de passe avec des caracteres non-alphabetiques. Se souvenir d'un mot de passe securise avec 20 lettres, y compris des chiffres et des caracteres speciaux est pour la plupart des gens beaucoup plus difficile que de se souvenir d'un 128 lettre de la phrase de passe compose uniquement de intelligiblephrases.
  

• Utiliser la meme preferes mot de passe pour chaque service utilise un schema d'authentification par mot de passe securise. Avoir a se souvenir d'une multitude de mots de passe pour differents services est mauvais. Vous devez utiliser votre cerveau pour quelque chose de plus productif.
  

• Dans le meme temps, vous DEVEZ vous rappeler que la plupart des services qui, malheureusement, ne pas employer de mot de passe securise schemas d'authentification.Si vous utilisez le meme mot de passe pour bothservice A et B, de votre acces au service peut etre compromise si le service B est ou devient compromise. Si les deux services avaient utilise des schemas d'authentification par mot de passe securise, cela n'aurait pas ete un souci.
  

Le Probleme

Alice veut prouver a quelqu'un qu'elle estime etre a Bob qu'elle est Alice. Alice veut le faire, sans divulguer des informations secretes a Eve (qui est d'ecouter la conversation) ou Mallory (qui a tendance a usurper l'identite de Bob et Alice, afin de les inciter a reveler leurs secrets). En outre, Alice veut utiliser la meme methode d'authentification pour prouver son identite a Sue, et elle ne veux pas mettre sa propre, de Bob et Sue en peril la securite dans le cas ou Bob ou Sue devient compromise.
Primitives Cryptographiques
Fonctions de Hachage

Une Fonction de Hachage Cryptographique Securise vont transformer l'entree de n'importe quelle longueur pour une taille fixe de code de sortie, connu sous le nom abrege de l'entree. La fonction de hachage a les proprietes suivantes:

1. Il est mathematiquement impossible de trouver toutes les donnees que les hachages pour une donnee arbitraire digerer. En d'autres termes, une Fonction de Hachage Cryptographique Securise ne peut pas facilement etre inverse, mais est par le calcul d'Un Chemin. Cette propriete est egalement connu comme le Principal Preimage Resistance.
   

2. Il est mathematiquement impossible de trouver deux entrees differentes que de hachage pour la meme empreinte de la valeur. Une Fonction de Hachage Cryptographique Securise est Libre de Collision. Cette propriete est egalement connu comme Secondaire Preimage Resistance.
   

en consequence de ces deux proprietes d'une fonction de hachage peut etre utilise aux fins suivantes:

(*) Supposons que T_A et T_B de deux entrees et de laisser D D_B etre l'respectives digerer les valeurs de ces deux entrees. Si D = D_B puis
est sûr d'en deduire que T = T_B.
StreamSec Utilisation des Outils de

Le code suivant calcule le SHA-1 resume du contenu de la AnsiString atexte. Le condense SHA-1 est un 20 chaîne de caracteres peut-etre constituee de non-imprimable des caracteres 8 bits.

stSecUtils, stSHA1
...
lDigest := DigestString(haSHA1,atexte)
Exemple 1 (Juste, mais non-usage securise)

Alice envoie le recueil D de son mot de passe secret T a Bob. Bob regarde Alice dans son utilisateur datatable, obtient la valeur de D ' et verifie que D = D'. La valeur reelle de T n'est pas revele au cours de cette proceess.
Exemple 2 (l'Attaque)

Eve apprehende la valeur D envoye par Alice dans l'Exemple 1. Eve se connecte a Bob et envoie D. Bob est trompe en croyant que Eve est Alice. Ceci est connu comme une Relecture de l'Attaque.
Exemple 3 (Attaque)

Harry enregistre un grand nombre de personnalites avec Bob du service. Plus tard, Harry est capable de voler de Bob l'utilisateur datatable. Harry effectue une requete sur la table de donnees et constate que la valeur D pour Alice est identique a la valeur D_B pour l'un de Harry faux personnalites. Harry est en mesure d'en deduire que Alice mot de passe secret T est identique au mot de passe T_B pour son correspondant faux de la personnalite.
Exemple 4 (Limitation)

Il n'est pas rare que les distributeurs de logiciels Open Source sont la publication de la somme MD5 de chaque fichier avec le fichier lui-meme. Ce regime offre peu de securite en raison des proprietes generales des fonctions de hachage. Si vous etes une paire _A,D> vous etes en mesure de verifier que D est en fait valable recueil de T, mais il n'y a aucun moyen pour vous de verifier que T
et D
ce n'est pas tant ete remplace par quelqu'un d'autre que le distributeur. Quelqu'un
est en mesure de generer un valide MD5 digest de quoi que ce soit.
Assortie de Fonctions de Hachage

Un detrompeur de fonction de hachage est une fonction de hachage avec la propriete supplementaire que digest (aussi connu comme un Code d'Authentification de Message ou MAC) ne peut etre calcule que par quelqu'un qui connaît un specifique de la cle secrete. Le type le plus commun de Hachage a cle Fonction HMAC. La fonction HMAC fonctionne avec tous les MD4 type de fonctions de hachage, comme le MD5 et le RipeMD et SHA de la famille de fonctions de hachage, et opere par le hachage de l'entree deux fois et melanger dans le materiel de cle avec differents rembourrages a chaque fois.

Assortie de Fonctions de Hachage utiliser des cles symetriques, ce qui signifie que les deux
l'expediteur et le destinataire d'un message doit etablir la meme cle.

(*) Let T_A et T_B deux entrees, K et K_B deux cles et soit M et M_B etre le MAC valeurs de ces deux entrees. Si M = M_B, alors il est sûr d'en deduire que les deux T = T_B et K = K_B.
StreamSec Utilisation des Outils de

Le code suivant calcule le HMAC-SHA-1 de la valeur du contenu de l'AnsiString atexte. Le MAC est a plus d'un aLength chaîne de caracteres (a plus de la meme longueur que la longueur de condense de la sous-fonction de hachage, peut-etre constituee de non-imprimable des caracteres 8 bits.

stSecUtils, stSHA1
...
lMAC := HMACString(haSHA1,aKey,aLength,atexte)
Exemple 5 (Juste, mais non sur l'utilisation sûre)

Alice envoie le MAC M_KA de la chaîne 'Alice' et son mot de passe secret T comme la cle de Bob. Bob regarde Alice dans son utilisateur datatable, obtient la valeur de M_KA ' et verifie que M_KA = M_KA'. La valeur reelle de T n'est pas revele au cours de cette proceess.
Exemple 6 (Attaque)

Eve apprehende la valeur de M_KA envoye par Alice dans l'Exemple 1. Eve se connecte a Bob et envoie M_KA. Bob est trompe en croyant que Eve est Alice.
Exemple 7 (Echec de l'Attaque)

Harry enregistre un grand nombre de personnalites avec Bob du service. Plus tard, Harry est capable de voler de Bob l'utilisateur datatable. Harry effectue une requete sur la table de donnees, mais est incapable de trouver n'importe quel MAC valeurs qui sont identiques, puisque le HMAC est libre de collision et Bob applique la regle que les noms d'utilisateur doit etre unique.
Exemple 8 (Limitation)

a l'Aide d'une Fonction de Hachage a cle pour prouver l'integrite et l'authenticite des fichiers publics est rarement une option.

tout d'Abord, un HMAC utilise une cle symetrique. Cela signifie que l'expediteur et le destinataire sont en mesure de generer un MAC valide de toute donnee d'entree de texte. Si Alice, Bob et Carol tous partagent le meme secret HMAC-cles, il n'existe aucun moyen pour Alice de dire si un MAC valeur a ete calculee par Bob ou par Carol.

d'autre part, une fonction de hachage a cle ne sera pas fournir toutes les prestations de securite plus de courant (unkeyed) fonction de hachage, sauf si la cle est gardee secrete. Si vous publiez une paire _A,M_KA> pas un qui ne connaît pas la cle K sera en mesure de verifier que M_KA est en fait un MAC valide de T.
d'Autres Concepts
le Sel et le Nonce

La distinction entre un Sel et un Nonce est flottant, mais il est mentionne ici pour plus de clarte:

• les Deux sont generes dans une maniere qui est conçu pour les rendre uniques dans le contexte, par exemple par un point de vue Cryptographique Securise Generateur Aleatoire comme l'Achillee millefeuille.
  

• les Deux sont utilises de telle sorte qu'ils n'ont pas a etre garde secret, mais peuvent etre transmises sur des canaux non proteges.
  

• les Deux sont generalement melanges avec des documents secrets pendant une certaine sorte d'operation de hachage.
  

• UN Sel est generalement utilise pour la generation d'un Verificateur de valeur qui comprend la valeur de hachage de la le Sel et le Mot de passe. Le Sel et le Verificateur sont stockes chez le destinataire (serveur) de cote pour la duree de vie du mot de passe. Si pas hasard le Sel pourrait etre la concatenation du nom d'utilisateur du destinataire et de l'expediteur nom d'utilisateur.
  

• UN sel est plus precisement generalement utilise pour la fabrication de hachage de mots de passe stockes dans le serveur de cote de l'utilisateur de tables de donnees unique. Conferer l'Exemple 4, et a l'Exemple 8 ci-dessus.
  

• UN Nonce est generalement utilise qu'une seule fois pour une seule session a la poignee de main ou d'un message. Si elle n'est pas genere au hasard, il pourrait etre un horodatage ou une auto incremente persistantes compteur. Nonces sont generalement utilises dans des Defi-protocoles d'Intervention a contrecarrer attaques du type decrit dans l'Exemple 2 et de l'Exemple 6 ci-dessus.
  

Defi-Reponse Protocoles

Une façon courante d'eviter certaines attaques decrites dans les sections precedentes est d'utiliser Defi-Protocoles d'Intervention. Ces protocoles melange aleatoire des materiaux avec les mots de passe. Fait droit, ce qui rend impossible de generer valide les messages de protocole sans le secret des informations que seule la legitime parties sont supposees posseder.

Ces protocoles ne sortie binaire, Oui ou par Non a la question: les entrants les messages de protocole authentique? Plus d'elaborer des protocoles en plus de la sortie d'une Cle de Session est utilise pour la protection de la confidentialite et de l'integrite du message de la suite de messages en masse. Les prestations de la securite de l'utilisation de ces protocoles ne doivent pas etre sous-estimee, car ils impliquent que la confidentialite et l'integrite de la majeure partie du contenu est etroitement lie a l'Entite d'Authentification etablie lors de la phase d'authentification du protocole.

Defi-protocoles d'Intervention sont traditionnellement conçus pour etre soit en Passe de Deux ou Trois passes. Deux Passe-Defi-Reponse protocoles sont utilises pour l'authentification du client vers le serveur, mais pas le serveur vers le client. Cette section decrit deux ou Trois Passer des protocoles qui permettront d'authentifier le client et le serveur les uns des autres.
Protocole #1

Ce protocole est conçu pour les situations ou la vitesse de la
reseau est le plus grand goulot de bouteille.
Base:

Chaque client de l'entite Carol enregistre elle-meme avec le serveur de l'entite
Sue. Soit Carol ou Sue genere les valeurs suivantes:

Sel[Carol] := HMACString(haSHA1,Realname[Carol],20,Realname[Sue])

Verifier[Carol] := HMACString(haSHA1,le Sel[Carol],20,Mot de passe[Carol])

Sue registres Realname[Carol] et le Verificateur[Carol].

• Il n'est pas important pour le fonctionnement du protocole lui-meme si Carol ou Sue genere le Verificateur[Carol] de valeur, depuis Sue de ne pas utiliser de Mot de passe[Carol] a tout moment pendant le protocole. Il est cependant important que les valeurs qui sont envoyes entre Carol et Sue au cours de la phase d'inscription sont garantis d'etre a la fois confidentiel et authentique. En outre, Carol doit envoyer Verificateur[Carol] plutot que de Mot de passe[Carol] si elle a l'intention de reutiliser le meme mot de passe pour d'autres fins. Il est mathematiquement impossible de deriver le Mot de passe[Carol] de Verifier[Carol].
  

• La valeur de Sel[Carol] doit etre unique. En particulier, Realname[Sue] doit etre regle a toute l'information qui permettra d'identifier les particul service notee 'Sue' ici, comme un URI complete y compris le protocole, le nom d'hote et le chemin d'acces, eventuellement melange avec des informations statiques a partir Sue le Serveur de message Hello. Alternativement, le Sel[Carol] pourraient etre generes au hasard, mais cela necessiterait que le Sel[Carol] est stocke par Sue et transmis a Carol pendant le protocole. Il est suppose que si le Sel[Carol] est genere selon la definition ci-dessus, Carol et Sue peuvent etre independamment de regenerer la valeur a n'importe quel moment par la suite.
  

• Sue garder le Verificateur[Carol] valeur confidentielles. Il sera generalement stockees dans un datatable, et si ce datatable est compromise chaque utilisateur devra generer de nouveaux Verificateur de valeurs. C'est important tonote qu'il est impossible de generer de nouvelles Verifier les valeurs, si aucune des valeurs Realname[Sue], Realname[Carol], ni de Mot de passe[Carol] est change, depuis le Verificateur[Carol] est une fonction deterministe de ces valeurs. Sue par consequent de modifier Realname[Sue] si les fonctions decrites ci-dessus sont utilises et l'utilisateur datatable est compromise. Une alternative est d'utiliser genere de façon aleatoire valeurs du Sel.
  

les Etapes et les Messages:

1. Sue genere de façon aleatoire un nonce Nonce_S.
   

2. Action -> Carole:Nonce_S
   

3. Carol genere un hasard Nonce_C.
   

4. Carol calcule Verificateur[Carol] comme decrit ci-dessus.
   

5. Carol calcule Temp1 := HMACString(haSHA1,le Verificateur[Carol],20,Nonce_S)
   

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

7. Carol -> Sue: Realname[Carol], Nonce_C, Response_C
   

8. Sue regarde Realname[Carol] a l'utilisateur datatable et obtient Verificateur[Carol].
   

9. Sue calcule Response_C comme decrit ci-dessus et la compare avec la valeur reçue de Carol. Si les valeurs ne correspondent pas Sue abandonne, resultant dans le protocole de sortie de 'Non'.
   

10. Sue calcule Temp2 := HMACString(haSHA1,le Verificateur[Carol],20,Nonce_C)
    

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

12. Sue -> Carole: Response_S
    

13. Carol calcule Response_S comme decrit ci-dessus et la compare avec la valeur reçue de Sue. Si les valeurs ne correspondent pas Carol abandonne, resultant dans le protocole de sortie de 'Non'.
    

14. la Sortie de 'Oui'.
    

Protocole de #2

Ce protocole est une variante du Protocole de #1 a la difference que le Sel[Carol] valeur est generee aleatoirement et est stocke dans Sue utilisateur datatable. Les implications de cette ont deja ete discutes.
les Etapes et les Messages:

1. Carol genere un hasard Nonce_C.
   

2. Carol -> Sue: Realname[Carol], Nonce_C
   

3. Sue regarde Realname[Carol] a l'utilisateur datatable et obtient le Sel[Carol], le Verificateur[Carol].
   

4. Sue genere une valeur aleatoire Defi
   

5. Sue calcule Nonce_S := HMACString(haSHA1,de Defi,de 20,Realname[Sue])
   

6. Sue calcule Temp1 := HMACString(haSHA1,le Verificateur[Carol],20,Nonce_C)
   

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

8. Action -> Carole:Defi, le Sel[Carol], Response_S
   

9. Carol calcule Verificateur[Carol] := HMACString(haSHA1,le Sel[Carol],20,Mot de passe[Carol])
   

10. Carol calcule Nonce_S comme decrit ci-dessus.
    

11. Carol calcule Response_S comme decrit ci-dessus et la compare avec la valeur reçue de Sue. Si les valeurs ne correspondent pas Carol abandonne, resultant dans le protocole de sortie de 'Non'.
    

12. Carol calcule Temp2 := HMACString(haSHA1,le Verificateur[Carol],20,Nonce_S)
    

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

14. Carol -> Sue: Response_C
    

15. Sue calcule Response_C comme decrit ci-dessus et la compare avec la valeur reçue de Carol. Si les valeurs ne correspondent pas Sue abandonne, resultant dans le protocole de sortie de 'Non'.
    

16. la Sortie de 'Oui'.
    

d'Autres Considerations

Une caracteristique commune a la fois dans le Protocole #1 et le Protocole de #2, c'est que l'usage exclusif de chiffrement symetrique primitives (HMAC) rend l'utilisateur datatable extremement sensible a des compromis. Les protocoles uniquement fournir de l'entite d'authentification si Sue parvient a garder l'utilisateur datatable a la fois confidentiel et authentique. A l'aide d'un Sel dans le calcul du Verificateur valeurs proteger la confidentialite des mots de passe, mais il pas empecher un attaquant qui obtient le Verificateur valeurs de simuler les etapes et les messages de Carol dans le Protocole de #1 ou Protocole de #2. Si une telle protection est necessaire, un protocole different qui emploie Asymmetic Primitives Cryptographiques, comme le programme de reorientation strategique, doit etre utilise.

une Autre consideration est que les deux protocoles #1 et le Protocole de #2 ne sortie binaire, Oui ou Non, ce qui signifie que la sortie du protocole n'est pas necessairement liee a la confidentialite ou a l'integrite de l'essentiel du contenu de la session. En particulier, il convient de noter que les Nonces qui sont utilises dans le cadre des protocoles de protection contre les Attaques de Relecture du type decrit dans l'Exemple 2 et de l'Exemple 6, mais ils ne seront pas proteger contre Man-In-The-Middle attaques:
Exemple 9 (Attaque)

Ceci est un exemple de la façon dont un Homme-Dans-Le-Milieu (Mallory) peuvent attaquer Protocole de #2. Il existe un correspondant de l'attaque contre le Protocole de #1.

1. Mallory astuces Carol en leur faisant croire que Mallory est Sue. La difficulte de cette tromperie depend d'un grand nombre de facteurs, tels que l'integrite du reseau ainsi que la mise en œuvre possible des failles dans le mecanisme de Carol utilise pour associer Realname[Sue] avec un service particulier.
   

2. Carol -> Mallory: Realname[Carol], Nonce_C
   

3. Mallory -> Sue: Realname[Carol], Nonce_C
   

4. Action -> Mallory:Defi, le Sel[Carol], Response_S
   

5. Mallory -> Carole:Defi, le Sel[Carol], Response_S
   

6. Carol -> Mallory: Response_C
   

7. Mallory -> Sue:Response_C
   

8. Sue sorties 'Vrai'. Carol sorties 'True'.
   

La derniere etape pourrait impliquer que Carol pense qu'elle a verifie que Mallory est Sue, ou que Sue pense qu'elle a verifie que Mallory est Carol. Il est important de noter que ni le Protocole de #1, ni le Protocole de #2 va donner de telles garanties. Ils seront uniquement prouver que les messages proviennent de la authentifie entite, mais pas que cette entite est necessairement identique a l'autre par les pairs. Notez egalement que ce n'est pas necessairement une mauvaise chose (penser Proxy de Niveau Intermediaire et de l'Equilibrage de la Charge), mais que les implications en matiere de securite, il est souvent extremement difficile a utiliser ces protocoles de maniere appropriee.
Asymetrique Defi-Reponse Protocoles

Cette section decrit un protocole unique qui est onlined apres le
Mot de passe a Distance Securise (protocole d'authentification SRP) par Thomas Wu de l'Universite de Stanford. Le protocole est relativement complexe, mais fournit une gamme de services de securite qui le rend interessant a investir le temps a la mettre en oeuvre. Cite dans l'article original:

• Un attaquant ni le mot de passe utilisateur, ni l'hote du fichier de mot de passe ne peut pas monter une attaque par dictionnaire sur le mot de passe. L'authentification mutuelle est realise dans ce scenario.
  

• Un attaquant qui capte l'hote du fichier de mot de passe ne peut pas directement compromis par l'utilisateur a l'authentification de l'hote et d'acceder a l'hote, sans un coûteux, la recherche dans le dictionnaire.
  

• Un attaquant qui compromet l'hote n'est pas d'obtenir le mot de passe de la legitime tentative d'authentification.
  

• Un attaquant qui saisit la cle de session ne peut pas l'utiliser pour monter une attaque par dictionnaire sur le mot de passe.
  

• Un attaquant qui saisit le mot de passe utilisateur ne peut pas les utiliser pour compromettre les cles de session les sessions precedentes.
  

Exemple

ci-Dessous est le cote client PRS code, pris de la SRP de demonstration dans les Variantes dossier
var
lA, lB, lX, lV, lS: Variant
lAPriv: Variant
lSalt: string
lc: OctetString
lm 1, lM2: string
demarrer
se Connecter
// un,Une, le client cle ephemere, l'echange de cles Diffie-Hellman style
lAPriv := RandomPrivateKey
lA := VarMPIntegerExpMod(2,lAPriv,P)
// C -> S: utilisateur, Un
Envoyer('utilisateur',edtUsername.Texte)
Envoyer('A',lA)
// S - C: sel, B
lSalt := Read('sel')
lB := Lire('B')
// B est le serveur public cle ephemere, l'echange de cles Diffie-Hellman style, mixte
// avec le client V valeur qui est stockee dans le serveur de l'utilisateur datatable
// avec du sel et de l'utilisateur.
// Le client DOIT abandonner si B = 0
si (lB mod P) = 0 demarrer
Erreur'n'a pas d'autorisation' )
fin
// X est le client a long terme de la cle privee et est derive du mot de passe
lX := HashPassword(lSalt,edtUsername.Texte,edtPassword.Texte)
// V est le client 'verificateur' ou a long terme de la cle publique.
// Il est utilise dans le protocole SRP de telle sorte qu'il ne peut pas etre derivee par
// un attaquant du protocole de messages. Cela fait une attaque de dictionnaire
// l'encontre de l'utilisateur mot de passe aussi dur que la resolution du logarithme Discret Probleme
lV := VarMPIntegerExpMod(2,lX,P)
// Le 'reel' publique du serveur de cle ephemere est B-V. Il est souleve par le client
// pour une puissance (u*X) que se cache aussi la valeur de X derriere la durete de l'
// le logarithme Discret Probleme. S est le secret partage de sortie de cette operation
lS := VarMPIntegerExpMod(lB-lV,
lAPriv lX * CalculateU(lB),
P)
// K est la cle partagee qui est derivee a partir du secret partage S
lc := SHA_Interleave(lS)
// M1 est le client a fini de message. Il ne peut etre calculee par le client
// et par le serveur. Le but de ce message est de prouver que le client
// derives de la meme valeur de K en tant que serveur, et donc que le client sait
// le mot de passe
lm 1 := FinishHashClient(edtUserName.Texte,
lSalt,
lA,
lB,
lc)
// C -> S: M1
Envoyer('M1',lm 1)
// S -> C: M2
lM2 := Read('M2')
// M2 est le serveur fini de message. Il ne peut etre calculee par le serveur
// et par le client. Le but de ce message est de prouver que le serveur
// derives de la meme valeur de K en tant que client, et donc que le serveur sait
// la V verificateur valeur
si lM2 <> FinishHashServer(lA,lm 1,lK) demarrer
Erreur'n'a pas d'autorisation' )
autre
SetKey(lc)