comportement de l'algorithme SSHA

Version imprimable

30/09/2008, 17h18
KalKul

comportement de l'algorithme SSHA

Bonjour à tous,

je ne sais pas si je suis dans le bon forum mais c'est ce qui me parait le plus approprié.
Dans le cas de SSHA (algorithme de cryptage) : normalement la génération d'une empreinte est différente pour une même valeur en entrée avec cette technique. Du coup je voulais savoir comment on faisait pour vérifier que le mot de passe d'une personne (par exemple) était bon puisque, si on le passe par SSHA on n'a pas la même empreinte... Y a-t-il une clef qui permet de retrouver le mot de passe de départ ?

Merci d'avance.

Bode
30/09/2008, 18h41
pseudocode

Citation:

Envoyé par KalKul

Dans le cas de SSHA (algorithme de cryptage) : normalement la génération d'une empreinte est différente pour une même valeur en entrée avec cette technique.

8O ??? Heu non... meme password + meme seed => meme hash

Citation:

Du coup je voulais savoir comment on faisait pour vérifier que le mot de passe d'une personne (par exemple) était bon puisque, si on le passe par SSHA on n'a pas la même empreinte...

Généralement on fait un challenge:
- Serveur: genere une seed aléatoire et l'envoie au client.
- Client: genere le hash pour (password+seed reçu) et l'envoie au serveur.
- Serveur: genere le hash pour (password+seed envoyé) et compare avec le hash reçu

Citation:

Y a-t-il une clef qui permet de retrouver le mot de passe de départ ?

Il faut esperer que non :aie:. (sauf cryptanalyse ou brute-force)
30/09/2008, 21h47
KalKul

impeccable, ça m'éclaire déjà beaucoup.
En fait je suis en train de regarder comment ldap fonctionne et il y a la possibilité de crypter les mots de passe grâce à SSHA. Sauf que lorsque j'utilise slappasswd pour en générer un il me donne des empreintes différentes à chaque fois ! Ben oui lais je ne connaissais pas. Et la, question...mais que se passe-t-il alors derrière pour que ça marche ça...?

Bon maintenant j'ai une partie de ma réponse.

Merci encore.:yaisse2:
30/09/2008, 22h33
pseudocode

Citation:

Envoyé par KalKul

impeccable, ça m'éclaire déjà beaucoup.
En fait je suis en train de regarder comment ldap fonctionne et il y a la possibilité de crypter les mots de passe grâce à SSHA. Sauf que lorsque j'utilise slappasswd pour en générer un il me donne des empreintes différentes à chaque fois ! Ben oui lais je ne connaissais pas. Et la, question...mais que se passe-t-il alors derrière pour que ça marche ça...?

il y a des chances pour que ton empreinte ait une taille de 24 octets. Auquel cas les 20 premiers octets devraient être le hash et les 4 derniers la seed.
27/08/2010, 11h00
Mathieu59

Challenge SSHA

Bonjour,

Désolé de déterrer un vieux sujet mais voilà les données de mon problème :
- dans OpenLDAP, le mot de passe est stocké en SSHA
- je souhaite faire circuler mon mot de passe de façon sécurisée, en l'envoyant encrypté également en SSHA depuis un client webmail par exemple

Mes questions :
- comment LDAP fait pour vérifier la validité du mot de passe compte-tenu du fait que la seed générée par le client est différente ?
- est-il judicieux d'utiliser ce mode de fonctionnement ?

Merci d'avance.
27/08/2010, 11h22
seeme

Bonjour,

Pour répondre rapidement à tes questions..

Ce n'est pas le client qui choisis la seed, mais le serveur (challenge). Donc pas de problème.

Cette méthode est tout à fait valable pour sécuriser les communications.
01/09/2010, 14h44
Jimmy_

Attention, le mot de passe ne circule pas crypté, mais hashé avec un algorithme de hashage cryptographique ici SHA. Ce qui est une grosse nuance.
Il faut aussi vérifié que l'on est au moins avec du SHA-256, car les versions SHA-0 et SHA-1 ont été cassées depuis quelques temps maintenant.

Comme expliqué déjà, le client génére le hash+seed reçu du serveur et envoie le résultat au serveur. Le serveur compare le résultat reçu avec son propre résultat.

Citation:

- est-il judicieux d'utiliser ce mode de fonctionnement ?

Oui car le mot de passe ne circule jamais même crypté. Seule une emprunte circule, on comprend facilement pourquoi.
En imaginant que l'attaquant intercepte le seed et le hash retourné par le client, il doit recalculer toute sa table de force brute à chaque seed. Ce qui est irréalisable en un temps raisonnable.
Les attaques sont possible sur des systèmes qui ne change pas de seed et qui utilise des algorithmes cassées comme MD5. Il est possible de fabrique des empruntes identique avec des messages différents. Donc cette emprunte n'est plus valide.