Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
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
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).
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
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
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" <no@no.com> a écrit dans le message de
news:40f2d701$0$24453$636a15ce@news.free.fr...
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
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
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
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
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
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
On Tue, 13 Jul 2004 08:38:07 +0200, Sylvain
<thefunny@dtc.for.spam.com> 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
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
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
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).
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
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
Super.
Merci beaucoup à tous.
"Clement Seveillac" <clemREMOVE@MEvia.ecp.fr> a écrit dans le message de
news:cd621v$nst$1@smilodon.ecp.fr...
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).
"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).