Bonjour =E0 tous,
Je suis en train de chercher une bonne m=E9thode d'authentification des
utilisateurs. Pour cela, j'utilise Openssl et plus pr=E9cisement
l'interface EVP qui donne acc=E9s aux fonctions de hachage. J'ai donc
d=E9cider d'utiliser le sha1. Cependant, j'aimerai savoir si c'est une
bonne alt=E9rnative d'une part, et d'autre part comment faire pour
r=E9duire la taille des empreintes de message obtenus en sortie. En
effet, contrairement au MD5, sha1 produit des hach=E9s de 160bits au
lieu de 128bits pour le MD5. J'ai crois qu'on peut r=E9duire =E0 64 bits
en faisant quelque op=E9rations sur les hachs sha1. Je m'interroge aussi
sur le cas ou deux utilisateurs auraient le meme mots de passe, =E0 ce
moment la le r=E9sultat de sha1 serait identique pour les deux et on
pourrait en d=E9duire qu'ils ont le meme mots de passe ce qui peut etre
g=E9nant. La solution serait d'utiliser des vecteurs d'initialisation ou
des salts ( comme pour la fonction crypt de unistd.h) mais en cherchent
dans les fonctions d'OpenSSL, je n'ai pas trouver des fonctions
permettant de r=E9aliser cela. J'ai trouver un example en C#
http://www.obviex.com/samples/hash.aspx permettant d'effectuer tout
cela.
Peut etre que quelqu'un est deja pass=E9 par la?
En tout cas merci et bon d=E9but de semaine.
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
:-\)
Pour éviter que 2 utilisateurs avec le même mot de passe aient le même hash, je calcule toujours le hash en concaténant le code utilisateur+le mot de passe.
"spacy" a écrit dans le message de news:
Bonjour à tous, Je suis en train de chercher une bonne méthode d'authentification des utilisateurs. Pour cela, j'utilise Openssl et plus précisement l'interface EVP qui donne accés aux fonctions de hachage. J'ai donc décider d'utiliser le sha1. Cependant, j'aimerai savoir si c'est une bonne altérnative d'une part, et d'autre part comment faire pour réduire la taille des empreintes de message obtenus en sortie. En effet, contrairement au MD5, sha1 produit des hachés de 160bits au lieu de 128bits pour le MD5. J'ai crois qu'on peut réduire à 64 bits en faisant quelque opérations sur les hachs sha1. Je m'interroge aussi sur le cas ou deux utilisateurs auraient le meme mots de passe, à ce moment la le résultat de sha1 serait identique pour les deux et on pourrait en déduire qu'ils ont le meme mots de passe ce qui peut etre génant. La solution serait d'utiliser des vecteurs d'initialisation ou des salts ( comme pour la fonction crypt de unistd.h) mais en cherchent dans les fonctions d'OpenSSL, je n'ai pas trouver des fonctions permettant de réaliser cela. J'ai trouver un example en C# http://www.obviex.com/samples/hash.aspx permettant d'effectuer tout cela. Peut etre que quelqu'un est deja passé par la? En tout cas merci et bon début de semaine.
Pour éviter que 2 utilisateurs avec le même mot de passe aient le même hash,
je calcule toujours le hash en concaténant le code utilisateur+le mot de
passe.
"spacy" <abspacy@yahoo.fr> a écrit dans le message de news:
1112606282.248543.193770@o13g2000cwo.googlegroups.com...
Bonjour à tous,
Je suis en train de chercher une bonne méthode d'authentification des
utilisateurs. Pour cela, j'utilise Openssl et plus précisement
l'interface EVP qui donne accés aux fonctions de hachage. J'ai donc
décider d'utiliser le sha1. Cependant, j'aimerai savoir si c'est une
bonne altérnative d'une part, et d'autre part comment faire pour
réduire la taille des empreintes de message obtenus en sortie. En
effet, contrairement au MD5, sha1 produit des hachés de 160bits au
lieu de 128bits pour le MD5. J'ai crois qu'on peut réduire à 64 bits
en faisant quelque opérations sur les hachs sha1. Je m'interroge aussi
sur le cas ou deux utilisateurs auraient le meme mots de passe, à ce
moment la le résultat de sha1 serait identique pour les deux et on
pourrait en déduire qu'ils ont le meme mots de passe ce qui peut etre
génant. La solution serait d'utiliser des vecteurs d'initialisation ou
des salts ( comme pour la fonction crypt de unistd.h) mais en cherchent
dans les fonctions d'OpenSSL, je n'ai pas trouver des fonctions
permettant de réaliser cela. J'ai trouver un example en C#
http://www.obviex.com/samples/hash.aspx permettant d'effectuer tout
cela.
Peut etre que quelqu'un est deja passé par la?
En tout cas merci et bon début de semaine.
Pour éviter que 2 utilisateurs avec le même mot de passe aient le même hash, je calcule toujours le hash en concaténant le code utilisateur+le mot de passe.
"spacy" a écrit dans le message de news:
Bonjour à tous, Je suis en train de chercher une bonne méthode d'authentification des utilisateurs. Pour cela, j'utilise Openssl et plus précisement l'interface EVP qui donne accés aux fonctions de hachage. J'ai donc décider d'utiliser le sha1. Cependant, j'aimerai savoir si c'est une bonne altérnative d'une part, et d'autre part comment faire pour réduire la taille des empreintes de message obtenus en sortie. En effet, contrairement au MD5, sha1 produit des hachés de 160bits au lieu de 128bits pour le MD5. J'ai crois qu'on peut réduire à 64 bits en faisant quelque opérations sur les hachs sha1. Je m'interroge aussi sur le cas ou deux utilisateurs auraient le meme mots de passe, à ce moment la le résultat de sha1 serait identique pour les deux et on pourrait en déduire qu'ils ont le meme mots de passe ce qui peut etre génant. La solution serait d'utiliser des vecteurs d'initialisation ou des salts ( comme pour la fonction crypt de unistd.h) mais en cherchent dans les fonctions d'OpenSSL, je n'ai pas trouver des fonctions permettant de réaliser cela. J'ai trouver un example en C# http://www.obviex.com/samples/hash.aspx permettant d'effectuer tout cela. Peut etre que quelqu'un est deja passé par la? En tout cas merci et bon début de semaine.
Kevin Drapel
J'ai crois qu'on peut réduire à 64 bits en faisant quelque opérations sur les hachs sha1.
Pourquoi utiliser SHA-1 dans ce cas ? Autant prendre un MD5 et couper l'empreinte en deux parties, ce sera plus rapide et au niveau de la sécurité, c'est la même chose (pour l'instant vu qu'il n'existe pas d'attaques sur les préimages).
J'ai crois qu'on peut réduire à 64 bits
en faisant quelque opérations sur les hachs sha1.
Pourquoi utiliser SHA-1 dans ce cas ? Autant prendre un MD5 et couper
l'empreinte en deux parties, ce sera plus rapide et au niveau de la
sécurité, c'est la même chose (pour l'instant vu qu'il n'existe pas
d'attaques sur les préimages).
J'ai crois qu'on peut réduire à 64 bits en faisant quelque opérations sur les hachs sha1.
Pourquoi utiliser SHA-1 dans ce cas ? Autant prendre un MD5 et couper l'empreinte en deux parties, ce sera plus rapide et au niveau de la sécurité, c'est la même chose (pour l'instant vu qu'il n'existe pas d'attaques sur les préimages).
spacy
Pour le md5 il existe un package crack-md5. Par contre le sha1 reste assez solide malgres le rapport d'un lab chinois affirmant avoir reussi à réaliser des collisions sur le sha affaibli. Je prefere donc utiliser le sha1. Pour le problème des empreintes identiques correspondant au meme mot de passe, j'ai pu le résoudre en concatenant un clé aléatoire à la fin de chaque mot de passe, cependant la longueur reste tjrs de 160 bits en sortie, et je n'ai rien trouvé pour pouvoir la diminuer.
Kevin Drapel wrote:
J'ai crois qu'on peut réduire à 64 bits en faisant quelque opérations sur les hachs sha1.
Pourquoi utiliser SHA-1 dans ce cas ? Autant prendre un MD5 et couper l'empreinte en deux parties, ce sera plus rapide et au niveau de la sécurité, c'est la même chose (pour l'instant vu qu'il n'existe pas
d'attaques sur les préimages).
Pour le md5 il existe un package crack-md5. Par contre le sha1 reste
assez solide malgres le rapport d'un lab chinois affirmant avoir reussi
à réaliser des collisions sur le sha affaibli. Je prefere donc
utiliser le sha1. Pour le problème des empreintes identiques
correspondant au meme mot de passe, j'ai pu le résoudre en
concatenant un clé aléatoire à la fin de chaque mot de passe,
cependant la longueur reste tjrs de 160 bits en sortie, et je n'ai rien
trouvé pour pouvoir la diminuer.
Kevin Drapel wrote:
J'ai crois qu'on peut réduire à 64 bits
en faisant quelque opérations sur les hachs sha1.
Pourquoi utiliser SHA-1 dans ce cas ? Autant prendre un MD5 et couper
l'empreinte en deux parties, ce sera plus rapide et au niveau de la
sécurité, c'est la même chose (pour l'instant vu qu'il n'existe
pas
Pour le md5 il existe un package crack-md5. Par contre le sha1 reste assez solide malgres le rapport d'un lab chinois affirmant avoir reussi à réaliser des collisions sur le sha affaibli. Je prefere donc utiliser le sha1. Pour le problème des empreintes identiques correspondant au meme mot de passe, j'ai pu le résoudre en concatenant un clé aléatoire à la fin de chaque mot de passe, cependant la longueur reste tjrs de 160 bits en sortie, et je n'ai rien trouvé pour pouvoir la diminuer.
Kevin Drapel wrote:
J'ai crois qu'on peut réduire à 64 bits en faisant quelque opérations sur les hachs sha1.
Pourquoi utiliser SHA-1 dans ce cas ? Autant prendre un MD5 et couper l'empreinte en deux parties, ce sera plus rapide et au niveau de la sécurité, c'est la même chose (pour l'instant vu qu'il n'existe pas
d'attaques sur les préimages).
Kevin Drapel
Pour le md5 il existe un package crack-md5.
Oui mais il s'agit d'une recherche avec des tables. SHA-1 pourrait tout à fait faire l'objet d'une telle attaque qui est générique (je pourrais lancer un projet crack-sha1 dès maintenant avec un peu de motivation et de temps devant moi) . Comme je l'ai dis dans l'autre message, il n'existe pas de méthode pratique pour trouver un message à partir d'une empreinte *quelconque* (cad. que la complexité dépend complètement du nombre de bits considérés). Si vous tronquez MD5 ou SHA-1 sur la même longueur, alors vous obtiendrez la même sécurité.
Mais il est vrai que SHA-1 semble plus robuste que MD5 si l'on regarde les attaques récentes, toutefois elles portent uniquement sur des collisions avec des messages au contenu aléatoire, il est difficile de tirer des conclusions sur d'hypothétiques attaques sur les préimages.
cependant la longueur reste tjrs de 160 bits en sortie, et je n'ai rien trouvé pour pouvoir la diminuer.
Les fonctions de hachage cryptographiques se comportent un peu comme des générateurs de nombres aléatoires. Une grande diffusion des bits à l'intérieur de l'architecture est présente, aucun bit de la sortie n'est "privilégié". Si vous voulez une sortie de 80 bits alors vous pourriez prendre les 80 premiers bits de l'empreinte, ou alors les 80 derniers bits ou encore un bit sur deux. Mais attention à ne pas trop diminuer la taille de la sortie ! 128 bits est un bon compromis si vous devez limiter la taille de l'empreinte.
Pour le md5 il existe un package crack-md5.
Oui mais il s'agit d'une recherche avec des tables. SHA-1 pourrait tout
à fait faire l'objet d'une telle attaque qui est générique (je pourrais
lancer un projet crack-sha1 dès maintenant avec un peu de motivation et
de temps devant moi) . Comme je l'ai dis dans l'autre message, il
n'existe pas de méthode pratique pour trouver un message à partir d'une
empreinte *quelconque* (cad. que la complexité dépend complètement du
nombre de bits considérés). Si vous tronquez MD5 ou SHA-1 sur la même
longueur, alors vous obtiendrez la même sécurité.
Mais il est vrai que SHA-1 semble plus robuste que MD5 si l'on regarde
les attaques récentes, toutefois elles portent uniquement sur des
collisions avec des messages au contenu aléatoire, il est difficile de
tirer des conclusions sur d'hypothétiques attaques sur les préimages.
cependant la longueur reste tjrs de 160 bits en sortie, et je n'ai
rien trouvé pour pouvoir la diminuer.
Les fonctions de hachage cryptographiques se comportent un peu comme des
générateurs de nombres aléatoires. Une grande diffusion des bits à
l'intérieur de l'architecture est présente, aucun bit de la sortie n'est
"privilégié". Si vous voulez une sortie de 80 bits alors vous pourriez
prendre les 80 premiers bits de l'empreinte, ou alors les 80 derniers
bits ou encore un bit sur deux. Mais attention à ne pas trop diminuer la
taille de la sortie ! 128 bits est un bon compromis si vous devez
limiter la taille de l'empreinte.
Oui mais il s'agit d'une recherche avec des tables. SHA-1 pourrait tout à fait faire l'objet d'une telle attaque qui est générique (je pourrais lancer un projet crack-sha1 dès maintenant avec un peu de motivation et de temps devant moi) . Comme je l'ai dis dans l'autre message, il n'existe pas de méthode pratique pour trouver un message à partir d'une empreinte *quelconque* (cad. que la complexité dépend complètement du nombre de bits considérés). Si vous tronquez MD5 ou SHA-1 sur la même longueur, alors vous obtiendrez la même sécurité.
Mais il est vrai que SHA-1 semble plus robuste que MD5 si l'on regarde les attaques récentes, toutefois elles portent uniquement sur des collisions avec des messages au contenu aléatoire, il est difficile de tirer des conclusions sur d'hypothétiques attaques sur les préimages.
cependant la longueur reste tjrs de 160 bits en sortie, et je n'ai rien trouvé pour pouvoir la diminuer.
Les fonctions de hachage cryptographiques se comportent un peu comme des générateurs de nombres aléatoires. Une grande diffusion des bits à l'intérieur de l'architecture est présente, aucun bit de la sortie n'est "privilégié". Si vous voulez une sortie de 80 bits alors vous pourriez prendre les 80 premiers bits de l'empreinte, ou alors les 80 derniers bits ou encore un bit sur deux. Mais attention à ne pas trop diminuer la taille de la sortie ! 128 bits est un bon compromis si vous devez limiter la taille de l'empreinte.
