Choix d'un algorithme

Le
Yo
Bonjour,

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 ?

Merci.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Francois Grieu
Le #22736011
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
Thomas Pornin
Le #22741891
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
Publicité
Poster une réponse
Anonyme