OVH Cloud OVH Cloud

Encryption de mots de passe

6 réponses
Avatar
Lc
Bonsoir,

Quel(s) algorythme(s) utiliser pour encrypter des mots de passe sensés
protéger l'accès à des applications?

Est-il correct de dire que l'algorythme utilisé par Windooz pour encrypter
nos mots de passe des formulaires web est super simple à craquer (lequel?)?

Autant de questions que je me pose pour sécuriser au mieux des applicatifs
(par ailleurs, sur des environnements divers).

Merci mille fois d'avance pour vos réponses,

Lc

6 réponses

Avatar
Franck Arnulfo
Lc wrote:
Bonsoir,


Bonsoir


Quel(s) algorythme(s) utiliser pour encrypter des mots de passe sensés
protéger l'accès à des applications?


Je crois que les plus utilisés sont MD5 et SHA-1.
Ce sont des algorithmes qui à partir d'une entrée (ton mot de passe en
clair) crée un condensé (hash en anglais) de taille fixe (32 bits par
exemple).
Les algos en jeu font qu'il est quasiment impossible de remonter au mot
de passe en clair à partir du hash.
L'utilisation est la suivante, tu stockes les hash (MD5 par ex.) en base
de données (ou serveur LDAP) pour chaque login, l'utilisateur veut se
connecter, il saisit son login puis son mot de passe en clair à
l'application, celle-ci le hash avec MD5 (en général cette partie est
déporté sur un serveur d'authentification) et compare le résultat avec
celui stocké en base, si c'est identique, il s'agit bien du bon mot de
passe.


Est-il correct de dire que l'algorythme utilisé par Windooz pour encrypter
nos mots de passe des formulaires web est super simple à craquer (lequel?)?


Je ne connais pas celui employé par Windows mais ce n'est pas le même
cas que pour MD5 ou SHA, car ici Windows doit fournir le mot de passe en
clair au formulaire web sans saisie de ta part.Cela implique qu'il doit
pouvoir revenir à la version non crypté de ton mot de passe, vu que tu
ne lui fournis rien en entrée, il doit se baser sur des données du
disque et c'est pour cela que l'on peut craquer cette protection.


Autant de questions que je me pose pour sécuriser au mieux des applicatifs
(par ailleurs, sur des environnements divers).

Merci mille fois d'avance pour vos réponses,

Lc





fa

Avatar
Lc
Si je te comprends bien, on ne stocke pas la valeur cryptée du mot de passe,
mais bien toujours le hash code qui lui correspond ???

"Franck Arnulfo" a écrit dans le message de
news:40f2d701$0$24453$
Lc wrote:
Bonsoir,


Bonsoir


Quel(s) algorythme(s) utiliser pour encrypter des mots de passe sensés
protéger l'accès à des applications?


Je crois que les plus utilisés sont MD5 et SHA-1.
Ce sont des algorithmes qui à partir d'une entrée (ton mot de passe en
clair) crée un condensé (hash en anglais) de taille fixe (32 bits par
exemple).
Les algos en jeu font qu'il est quasiment impossible de remonter au mot
de passe en clair à partir du hash.
L'utilisation est la suivante, tu stockes les hash (MD5 par ex.) en base
de données (ou serveur LDAP) pour chaque login, l'utilisateur veut se
connecter, il saisit son login puis son mot de passe en clair à
l'application, celle-ci le hash avec MD5 (en général cette partie est
déporté sur un serveur d'authentification) et compare le résultat avec
celui stocké en base, si c'est identique, il s'agit bien du bon mot de
passe.


Est-il correct de dire que l'algorythme utilisé par Windooz pour
encrypter


nos mots de passe des formulaires web est super simple à craquer
(lequel?)?



Je ne connais pas celui employé par Windows mais ce n'est pas le même
cas que pour MD5 ou SHA, car ici Windows doit fournir le mot de passe en
clair au formulaire web sans saisie de ta part.Cela implique qu'il doit
pouvoir revenir à la version non crypté de ton mot de passe, vu que tu
ne lui fournis rien en entrée, il doit se baser sur des données du
disque et c'est pour cela que l'on peut craquer cette protection.


Autant de questions que je me pose pour sécuriser au mieux des
applicatifs


(par ailleurs, sur des environnements divers).

Merci mille fois d'avance pour vos réponses,

Lc





fa



Avatar
Sylvain
Lc a écrit le Monday 12 July 2004 22:35 :


Si je te comprends bien, on ne stocke pas la valeur cryptée du mot de
passe, mais bien toujours le hash code qui lui correspond ???



Oui, etant donne que le hash est unique pour chaque mots de passe, il
suffit de le re-calculer et le comparer avec le hash stocke. C'est comme ca
que les systeme d'authentification correct fonctionne, car il permet une
authentification sur sans ne pouvoir jamais au grand jamais donne le pass
qu'il faut en clair.

--
Combien de jeunes talents confinés dans une mansarde s'étiolent et
périssent faute d'un ami.
BALZAC, Peau chagr., 1831, p. 12

Avatar
Fabrice..Bacchella
On Tue, 13 Jul 2004 08:38:07 +0200, Sylvain
wrote:

Lc a écrit le Monday 12 July 2004 22:35 :


Si je te comprends bien, on ne stocke pas la valeur cryptée du mot de
passe, mais bien toujours le hash code qui lui correspond ???



Oui, etant donne que le hash est unique pour chaque mots de passe, il
suffit de le re-calculer et le comparer avec le hash stocke. C'est comme ca
que les systeme d'authentification correct fonctionne, car il permet une
authentification sur sans ne pouvoir jamais au grand jamais donne le pass
qu'il faut en clair.


Mais il a l'inconvenient de pouvoir rejouer les mots de passes sur un
accès réseau. C'est toujours la même information qui circule. Un mot
de passe stocké sous forme claire ou avec une fonction de chiffrement
à sens unique permet d'utiliser des méthodes contournant ce problème.
---
http://fba.homeip.net


Avatar
Clement Seveillac
Franck Arnulfo wrote:
Je crois que les plus utilisés sont MD5 et SHA-1.
Ce sont des algorithmes qui à partir d'une entrée (ton mot de passe en
clair) crée un condensé (hash en anglais) de taille fixe (32 bits par
exemple).
Les algos en jeu font qu'il est quasiment impossible de remonter au mot
de passe en clair à partir du hash.


Les algos sont senses garantir qu'il n'y a pas mieux que la force brute
(pour trouver A - ici un mot de passe - tel que hash(A) = B, on essaie
tous les A possibles jusqu'a trouver celui dont le hash est egal a B :)

Le probleme depend alors forcement de la variete des A en entree : si ce
ne sont que des lettres minuscules ou majuscules, de 8 lettres au plus,
on aura tot fait de tous les tester (en s'aidant eventuellement de bases
de donnees pregenerees, cf. compromis temps/memoire dont on parlait il y
a dix jours ici, ou http://passcracking.com/).

Pour eviter ce risque, mieux vaut "saler" (salt en anglais) son A avant
de le hasher, ce qui permet d'eviter a certains de s'aider de BDD
pregenerees, et met a l'abri de la force brute tout mot de passe qui se
respecter (>=8 caracteres majuscules, minuscules, chiffres et meme
ponctuation). Bien sur, la majorite des utilisateurs n'emploient
d'eux-meme pas des mots de passe serieux ;)

Enfin, si on veut bien faire les choses, on choisira SHA-1 plutot que
MD5, un peu moins puissant, mais les risques exposes precedemment sont
plus graves qu'une utilisation de MD5 par rapport a autre chose.


[Quant a l'authentification web]


Sans SSL ou autre methode d'authentification/chiffrement, le mot de
passe des formulaires web circule effectivement en clair (codé en base
64, mais non chiffré).

Envoyer le hash du mot de passe n'est pas non plus sur, car il suffit
d'ecouter ce hash et de le "rejouer" (replay attack). Une methode un peu
plus sure est la methode du "defi - reponse" (challenge-response) : le
serveur genere un numero unique, et on lui renvoie un produit de son mot
de passe et de ce numero unique (evite les attaques par rejeu, et evite
bien sur de decouvrir le mot de passe).

En esperant que ca aide :)
--
clem

Avatar
Lc
Super.

Merci beaucoup à tous.

"Clement Seveillac" a écrit dans le message de
news:cd621v$nst$
Franck Arnulfo wrote:
Je crois que les plus utilisés sont MD5 et SHA-1.
Ce sont des algorithmes qui à partir d'une entrée (ton mot de passe en
clair) crée un condensé (hash en anglais) de taille fixe (32 bits par
exemple).
Les algos en jeu font qu'il est quasiment impossible de remonter au mot
de passe en clair à partir du hash.


Les algos sont senses garantir qu'il n'y a pas mieux que la force brute
(pour trouver A - ici un mot de passe - tel que hash(A) = B, on essaie
tous les A possibles jusqu'a trouver celui dont le hash est egal a B :)

Le probleme depend alors forcement de la variete des A en entree : si ce
ne sont que des lettres minuscules ou majuscules, de 8 lettres au plus,
on aura tot fait de tous les tester (en s'aidant eventuellement de bases
de donnees pregenerees, cf. compromis temps/memoire dont on parlait il y
a dix jours ici, ou http://passcracking.com/).

Pour eviter ce risque, mieux vaut "saler" (salt en anglais) son A avant
de le hasher, ce qui permet d'eviter a certains de s'aider de BDD
pregenerees, et met a l'abri de la force brute tout mot de passe qui se
respecter (>=8 caracteres majuscules, minuscules, chiffres et meme
ponctuation). Bien sur, la majorite des utilisateurs n'emploient
d'eux-meme pas des mots de passe serieux ;)

Enfin, si on veut bien faire les choses, on choisira SHA-1 plutot que
MD5, un peu moins puissant, mais les risques exposes precedemment sont
plus graves qu'une utilisation de MD5 par rapport a autre chose.


[Quant a l'authentification web]


Sans SSL ou autre methode d'authentification/chiffrement, le mot de
passe des formulaires web circule effectivement en clair (codé en base
64, mais non chiffré).

Envoyer le hash du mot de passe n'est pas non plus sur, car il suffit
d'ecouter ce hash et de le "rejouer" (replay attack). Une methode un peu
plus sure est la methode du "defi - reponse" (challenge-response) : le
serveur genere un numero unique, et on lui renvoie un produit de son mot
de passe et de ce numero unique (evite les attaques par rejeu, et evite
bien sur de decouvrir le mot de passe).

En esperant que ca aide :)
--
clem