3 Wrong Ways to Store a Password - Adam Bard and his magical blog - Le Hollandais Volant
mardi 20 janvier 2015 à 10:27HowTommy | Liens et actu en vrac 20/01/2015
Ce que le mec explique surtout (et il a parfaitement raison), c'est que SHA et MD5 sont conçus pour être RAPIDES ! Du coup, même avec de longs mots de passes et de longs sels, générer des rainbow tables prendra un temps acceptable.
Même si aujourd'hui c'est long (et encore), dans quelques années ça ne prendra quasiment plus de temps. Alors imagine avec une ferme de serveurs ou la puissance du Cloud derrière soi.
C'est pour ça qu'il parle de pbkdf2 et bcrypt. Ces deux algos sont conçus spécialement pour être lents. Ainsi générer des rainbow tables prendra un temps monstre, alors que le temps de génération du hash est acceptable à la connexion d'un utilisateur.
Et oui, dans tous les cas, les mots de passe sont souvent trop courts et pas assez complexes. Mais en cas de fuite de données, la façon de stocker les mots de passe est aussi importante que la complexité de ces derniers.
(Permalink)
Ce que le mec explique surtout (et il a parfaitement raison), c'est que SHA et MD5 sont conçus pour être RAPIDES ! Du coup, même avec de longs mots de passes et de longs sels, générer des rainbow tables prendra un temps acceptable.
Même si aujourd'hui c'est long (et encore), dans quelques années ça ne prendra quasiment plus de temps. Alors imagine avec une ferme de serveurs ou la puissance du Cloud derrière soi.
C'est pour ça qu'il parle de pbkdf2 et bcrypt. Ces deux algos sont conçus spécialement pour être lents. Ainsi générer des rainbow tables prendra un temps monstre, alors que le temps de génération du hash est acceptable à la connexion d'un utilisateur.
Et oui, dans tous les cas, les mots de passe sont souvent trop courts et pas assez complexes. Mais en cas de fuite de données, la façon de stocker les mots de passe est aussi importante que la complexité de ces derniers.
(Permalink)