Je développe une application dans laquelle je souhaite stocker dans ma
base de données la signature (résultant d'un "hash"age) des mots de
passe des utilisateurs, plutôt que les mots de passe eux même.
Jusqu'ici j'utilisais l'algorithme SHA1 disponible dans ma base de
données. Toutefois, j'ai entendu dire que cet algo était trop faible,
voire avait été cassé, et qu'un SHA512() était plus conseillé.
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
Francois Grieu
Le 27/10/2010 17:20, Yo a écrit :
Je développe une application dans laquelle je souhaite stocker dans ma base de données la signature (résultant d'un "hash"age) des mots de passe des utilisateurs, plutôt que les mots de passe eux même.
Jusqu'ici j'utilisais l'algorithme SHA1 disponible dans ma base de données. Toutefois, j'ai entendu dire que cet algo était trop faible, voire avait été cassé, et qu'un SHA512() était plus conseillé.
Pouvez vous confirmer ces informations ?
Je confirme que l'algorithme SHA-1 est en théorie cassé pour sa résistance aux collisions http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersion.pdf http://csrc.nist.gov/groups/ST/hash/documents/Wang_SHA1-New-Result.pdf http://eprint.iacr.org/2007/474
*Mais* dans l'application décrite cela n'a aucune importance ! SHA-512 est à peine moins mauvais que SHA-1 dans cette application, et ce essentiellement car il est un peu moins rapide.
Le fait est que stocker le hash de mots de passe donne une protection faible. Si la liste des hash devient publique (ce qui est la motivation de l'opération), il est extrêmement facile de calculer le hash des mots de passe les plus courants, et de voir si leur hash apparait dans la liste. Noter que l'effort de l'attaquant pour trouver un mot de passe est presqueinversement proportionnel au nombre d'utilisateurs !
Un premier pas est d'ajouter du "sel", cad une valeur arbitraire différente pour chaque utilisateur, qui est hashée avec le mot de passe. A défaut de mieux, le sel peut être l'identifiant de l'utilisateur concaténé à une constante arbitraire dépendant du serveur. L'effort de l'attaquant pour trouver un mot de passe devient une constante (mais en pratique, trop petite pour une protection efficace).
Un pas supplémentaire est de choisir une fonction délibérément ralentie, au lien d'un simple hash (qui en général est optimisé pour être réalisable rapidement). Si il faut bricoler quelque chose à base de SHA-1 (ce qui est souvent un choix plausible, en particulier quand une contrainte est que le serveur doit être écrit dans un langage où tout calcul non natif est lent), il y a pire que: x := constante_arbitraire_unique_au_serveur répéter N fois x := SHA-1(x # mot_de_passe # nom_utilisateur) avec N une constante aussi grande que tolérable compte tenu de la puissance du CPU du serveur (N000 voire bien davantage est tolérable dans certaines applications). L'effort de l'adversaire pour trouver un mot de passe croit en proportion de N.
Une mesure orthogonale à tout ceci est de stocker le fichier des (hash de) mots de passe chiffré avec une clé conservée à part. Ca peut donner une protection contre, par exemple, une attaque effectuée à partir de "backups".
Tout ça reste moins que très bon comme protection en cas de compromission du serveur, mais tout ce que je connais de mieux possède au moins un inconvénient parmi: - sécurité par l'obscurité - nécessité de hardware spécifique côté serveur - nécessité d'un algorithme côté client
François Grieu
Le 27/10/2010 17:20, Yo a écrit :
Je développe une application dans laquelle je souhaite stocker
dans ma base de données la signature (résultant d'un "hash"age)
des mots de passe des utilisateurs, plutôt que les mots de passe
eux même.
Jusqu'ici j'utilisais l'algorithme SHA1 disponible dans ma base
de données. Toutefois, j'ai entendu dire que cet algo était trop
faible, voire avait été cassé, et qu'un SHA512() était plus
conseillé.
Pouvez vous confirmer ces informations ?
Je confirme que l'algorithme SHA-1 est en théorie cassé pour
sa résistance aux collisions
http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersion.pdf
http://csrc.nist.gov/groups/ST/hash/documents/Wang_SHA1-New-Result.pdf
http://eprint.iacr.org/2007/474
*Mais* dans l'application décrite cela n'a aucune importance !
SHA-512 est à peine moins mauvais que SHA-1 dans cette application,
et ce essentiellement car il est un peu moins rapide.
Le fait est que stocker le hash de mots de passe donne une
protection faible. Si la liste des hash devient publique
(ce qui est la motivation de l'opération), il est extrêmement
facile de calculer le hash des mots de passe les plus courants,
et de voir si leur hash apparait dans la liste. Noter que
l'effort de l'attaquant pour trouver un mot de passe est
presqueinversement proportionnel au nombre d'utilisateurs !
Un premier pas est d'ajouter du "sel", cad une valeur arbitraire
différente pour chaque utilisateur, qui est hashée avec le mot
de passe. A défaut de mieux, le sel peut être l'identifiant de
l'utilisateur concaténé à une constante arbitraire dépendant
du serveur. L'effort de l'attaquant pour trouver un mot de passe
devient une constante (mais en pratique, trop petite pour une
protection efficace).
Un pas supplémentaire est de choisir une fonction délibérément
ralentie, au lien d'un simple hash (qui en général est optimisé
pour être réalisable rapidement).
Si il faut bricoler quelque chose à base de SHA-1 (ce qui est
souvent un choix plausible, en particulier quand une contrainte
est que le serveur doit être écrit dans un langage où tout
calcul non natif est lent), il y a pire que:
x := constante_arbitraire_unique_au_serveur
répéter N fois
x := SHA-1(x # mot_de_passe # nom_utilisateur)
avec N une constante aussi grande que tolérable compte tenu
de la puissance du CPU du serveur (N000 voire bien davantage
est tolérable dans certaines applications). L'effort de
l'adversaire pour trouver un mot de passe croit en proportion
de N.
Une mesure orthogonale à tout ceci est de stocker le fichier
des (hash de) mots de passe chiffré avec une clé conservée
à part. Ca peut donner une protection contre, par exemple,
une attaque effectuée à partir de "backups".
Tout ça reste moins que très bon comme protection en cas de
compromission du serveur, mais tout ce que je connais de mieux
possède au moins un inconvénient parmi:
- sécurité par l'obscurité
- nécessité de hardware spécifique côté serveur
- nécessité d'un algorithme côté client
Je développe une application dans laquelle je souhaite stocker dans ma base de données la signature (résultant d'un "hash"age) des mots de passe des utilisateurs, plutôt que les mots de passe eux même.
Jusqu'ici j'utilisais l'algorithme SHA1 disponible dans ma base de données. Toutefois, j'ai entendu dire que cet algo était trop faible, voire avait été cassé, et qu'un SHA512() était plus conseillé.
Pouvez vous confirmer ces informations ?
Je confirme que l'algorithme SHA-1 est en théorie cassé pour sa résistance aux collisions http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersion.pdf http://csrc.nist.gov/groups/ST/hash/documents/Wang_SHA1-New-Result.pdf http://eprint.iacr.org/2007/474
*Mais* dans l'application décrite cela n'a aucune importance ! SHA-512 est à peine moins mauvais que SHA-1 dans cette application, et ce essentiellement car il est un peu moins rapide.
Le fait est que stocker le hash de mots de passe donne une protection faible. Si la liste des hash devient publique (ce qui est la motivation de l'opération), il est extrêmement facile de calculer le hash des mots de passe les plus courants, et de voir si leur hash apparait dans la liste. Noter que l'effort de l'attaquant pour trouver un mot de passe est presqueinversement proportionnel au nombre d'utilisateurs !
Un premier pas est d'ajouter du "sel", cad une valeur arbitraire différente pour chaque utilisateur, qui est hashée avec le mot de passe. A défaut de mieux, le sel peut être l'identifiant de l'utilisateur concaténé à une constante arbitraire dépendant du serveur. L'effort de l'attaquant pour trouver un mot de passe devient une constante (mais en pratique, trop petite pour une protection efficace).
Un pas supplémentaire est de choisir une fonction délibérément ralentie, au lien d'un simple hash (qui en général est optimisé pour être réalisable rapidement). Si il faut bricoler quelque chose à base de SHA-1 (ce qui est souvent un choix plausible, en particulier quand une contrainte est que le serveur doit être écrit dans un langage où tout calcul non natif est lent), il y a pire que: x := constante_arbitraire_unique_au_serveur répéter N fois x := SHA-1(x # mot_de_passe # nom_utilisateur) avec N une constante aussi grande que tolérable compte tenu de la puissance du CPU du serveur (N000 voire bien davantage est tolérable dans certaines applications). L'effort de l'adversaire pour trouver un mot de passe croit en proportion de N.
Une mesure orthogonale à tout ceci est de stocker le fichier des (hash de) mots de passe chiffré avec une clé conservée à part. Ca peut donner une protection contre, par exemple, une attaque effectuée à partir de "backups".
Tout ça reste moins que très bon comme protection en cas de compromission du serveur, mais tout ce que je connais de mieux possède au moins un inconvénient parmi: - sécurité par l'obscurité - nécessité de hardware spécifique côté serveur - nécessité d'un algorithme côté client
François Grieu
Thomas Pornin
According to Francois Grieu :
SHA-512 est à peine moins mauvais que SHA-1 dans cette application, et ce essentiellement car il est un peu moins rapide.
Notons au passage que SHA-512 est moins rapide que SHA-1, mais tout de même très rapide (il est fort rare que la vitesse d'une fonction de hachage soit source de ralentissement dans une application donnée). De plus, si on ralentit sciemment l'application de la fonction (en hachant moult copies successive du mot de passe et du sel, par exemple), alors cette notion de performance disparaît complètement : on ajuste le nombre de copies pour atteindre une cible de performance donnée.
SHA-512 (ou son petit frère SHA-256) est recommandé parce que c'est la recommandation par défaut. SHA-1 est une mauvaise publicité : si on utilise SHA-1, il faut s'attendre à devoir se justifier (quand bien même cette justification est facile).
--Thomas Pornin
According to Francois Grieu <fgrieu@gmail.com>:
SHA-512 est à peine moins mauvais que SHA-1 dans cette application,
et ce essentiellement car il est un peu moins rapide.
Notons au passage que SHA-512 est moins rapide que SHA-1, mais tout de
même très rapide (il est fort rare que la vitesse d'une fonction de
hachage soit source de ralentissement dans une application donnée). De
plus, si on ralentit sciemment l'application de la fonction (en hachant
moult copies successive du mot de passe et du sel, par exemple), alors
cette notion de performance disparaît complètement : on ajuste le nombre
de copies pour atteindre une cible de performance donnée.
SHA-512 (ou son petit frère SHA-256) est recommandé parce que c'est
la recommandation par défaut. SHA-1 est une mauvaise publicité : si
on utilise SHA-1, il faut s'attendre à devoir se justifier (quand bien
même cette justification est facile).
SHA-512 est à peine moins mauvais que SHA-1 dans cette application, et ce essentiellement car il est un peu moins rapide.
Notons au passage que SHA-512 est moins rapide que SHA-1, mais tout de même très rapide (il est fort rare que la vitesse d'une fonction de hachage soit source de ralentissement dans une application donnée). De plus, si on ralentit sciemment l'application de la fonction (en hachant moult copies successive du mot de passe et du sel, par exemple), alors cette notion de performance disparaît complètement : on ajuste le nombre de copies pour atteindre une cible de performance donnée.
SHA-512 (ou son petit frère SHA-256) est recommandé parce que c'est la recommandation par défaut. SHA-1 est une mauvaise publicité : si on utilise SHA-1, il faut s'attendre à devoir se justifier (quand bien même cette justification est facile).
