SHA1 vs md5 vs SHA256 : lequel utiliser pour une connexion PHP ?

Question

Je crée une connexion php et j'essaie de décider si je dois utiliser SHA1 ou Md5, ou SHA256, dont j'ai entendu parler dans un autre article de stackoverflow. L'un d'entre eux est-il plus sûr que les autres ? Pour SHA1/256, dois-je toujours utiliser un sel ?

De plus, est-ce un moyen sûr de stocker le mot de passe sous forme de hachage dans mysql ?

function createSalt()
{
    $string = md5(uniqid(rand(), true));
    return substr($string, 0, 3);
}

$salt = createSalt();

$hash = sha1($salt . $hash);

Answer 1

Ni l'un ni l'autre. Vous devez utiliser bcrypt . Les hachages que vous mentionnez sont tous optimisés pour être rapides et faciles sur le matériel, et leur craquage partage donc les mêmes qualités. Si vous n'avez pas d'autre choix, assurez-vous au moins d'utiliser un sel long et de ré-échantillonner plusieurs fois.

Answer 2

Je pense que l'utilisation de md5 ou de sha256 ou de tout autre hachage optimisé pour la vitesse est parfaitement acceptable et je suis très curieux d'entendre la réfutation d'autres utilisateurs. Voici mes raisons

1. Si vous autorisez les utilisateurs à utiliser des mots de passe faibles tels que Dieu, amour, guerre, paix, alors quel que soit le cryptage, vous autoriserez toujours l'utilisateur à taper le mot de passe et non le hachage, et ces mots de passe sont souvent utilisés en premier. PAS va avoir quelque chose à voir avec le cryptage.

2. Si vous n'utilisez pas SSL ou si vous n'avez pas de certificat, les attaquants qui écoutent le trafic seront en mesure d'extraire le mot de passe et toute tentative de cryptage avec javascript ou autre est côté client et facilement craquée et surmontée. Encore une fois, ceci est PAS n'aura rien à voir avec le cryptage des données du côté du serveur.

3. Les attaques par force brute profitent des mots de passe faibles et, comme vous autorisez l'utilisateur à saisir les données, si vous ne limitez pas le nombre de connexions à 3 ou même un peu plus, le problème se reproduira. PAS n'ont rien à voir avec le cryptage des données.

4. Si votre base de données est compromise, il est probable que tout a été compromis, y compris vos techniques de hachage, même si elles sont cryptées. Il peut s'agir d'une attaque XSS ou d'une injection SQL par un employé mécontent ou d'une autre attaque qui n'a rien à voir avec le cryptage de votre mot de passe.

Je pense qu'il faut quand même crypter mais la seule chose que je vois que le cryptage fait est d'empêcher les personnes qui ont déjà ou qui ont obtenu d'une manière ou d'une autre l'accès à la base de données de simplement lire à haute voix le mot de passe. S'il s'agit d'une personne non autorisée à accéder à la base de données, alors vous avez de plus gros problèmes à résoudre. C'est pourquoi Sony s'est fait prendre parce qu'ils pensaient qu'un mot de passe crypté protégeait tout, y compris les numéros de carte de crédit, mais il ne protège qu'un seul champ, c'est tout.

Le seul avantage pur que je vois au cryptage complexe des mots de passe dans une base de données est d'empêcher les employés ou d'autres personnes ayant accès à la base de données de lire simplement les mots de passe. Donc, s'il s'agit d'un petit projet, je ne m'inquiéterais pas trop de la sécurité du côté serveur, mais plutôt de la sécurité de tout ce qu'un client peut envoyer au serveur, comme les injections SQL, les attaques XSS ou la pléthore d'autres façons dont vous pouvez être compromis. Si quelqu'un n'est pas d'accord, j'ai hâte de lire un article expliquant qu'un mot de passe super crypté est indispensable du côté client.

La raison pour laquelle je voulais essayer de clarifier ce point est que, trop souvent, les gens pensent qu'un mot de passe crypté signifie qu'ils n'ont pas à s'inquiéter de sa compromission et qu'ils cessent de se soucier de la sécurisation du site web.

Answer 3

Comme l'a souligné Johannes Gorset, le billet de Thomas Ptacek de Matasano Security explique pourquoi les fonctions de hachage simples et générales, telles que MD5, SHA1, SHA256 et SHA512, sont de mauvais choix pour le hachage des mots de passe. .

Pourquoi ? Ils sont trop rapides. Un ordinateur moderne peut calculer au moins 1 000 000 de hachages MD5 par seconde et par cœur, de sorte que la force brute est possible contre la plupart des mots de passe utilisés. Et c'est beaucoup moins qu'un cluster de serveurs de craquage basé sur les GPU !

Le salage sans étirement des clés signifie seulement que vous ne pouvez pas précalculer la table arc-en-ciel, vous devez la construire ad hoc pour ce sel spécifique. Mais cela ne rendra pas les choses beaucoup plus difficiles.

L'utilisateur @Will dit :

Tout le monde en parle comme s'ils pouvaient être piratés sur Internet. Comme nous l'avons déjà dit, la limitation des tentatives rend impossible de impossible de craquer un mot de passe sur internet et n'a rien à voir avec le hachage.

Ils n'en ont pas besoin. Apparemment, dans le cas de LinkedIn ils ont utilisé le commun Vulnérabilité à l'injection SQL pour obtenir la table de la base de données de connexion et a craqué des millions de mots de passe hors ligne.

Puis il revient au scénario d'attaque hors ligne :

La sécurité entre vraiment en jeu lorsque la base de données entière est compromise et qu'un pirate peut alors effectuer 100 millions de tentatives de mot de passe par seconde contre le hachage md5. SHA512 est environ 10,000 fois fois plus lent.

Non, SHA512 n'est pas 10000 fois plus lent que MD5 - il ne prend que deux fois plus de temps. Crypt/SHA512 est une bête très différente qui, comme son homologue BCrypt, exécute les tâches suivantes étirement clé Il faut entre 500 et 999999 fois plus de temps pour le calculer (l'extension est réglable).

SHA512 => aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d
Crypt/SHA512 => $6$rounds=5000$usesomesillystri$D4IrlXatmP7rx3P3InaxBeoomnAihCKRVQP22JZ6EY47Wc6BkroIuUUBOov1i.S5KPgErtP/EN5mcO.ChWQW21

Le choix pour PHP est donc soit Crypt/Blowfish (BCrypt), Crypt/SHA256 ou Crypt/SHA512. Ou au moins Crypt/MD5 (PHK). Voir www.php.net/manual/en/function.crypt.php

Answer 4

Utilisez SHA256 . Il n'est pas parfait, comme SHA512 serait idéal pour un hachage rapide, mais parmi les options, c'est le choix définitif. Comme pour toute technologie de hachage, veillez à saler le hachage pour plus de sécurité.

En outre, FRKT, veuillez me montrer où quelqu'un peut facilement craquer un hachage SHA256 salé ? Je suis vraiment très intéressé de voir cela.

Modification importante :

Pour l'avenir, veuillez utiliser bcrypt comme un hachage renforcé. De plus amples informations peuvent être trouvé ici .

---

Edit sur le salage :

Utilisez un nombre aléatoire, ou un flux d'octets aléatoires, etc. Vous pouvez également utiliser le champ unique de l'enregistrement dans votre base de données comme sel, de cette façon le sel est différent par utilisateur.

Answer 5

Ce que les gens semblent oublier, c'est que si le pirate a accès à la base de données, il a probablement aussi accès au fichier php qui hache le mot de passe et peut probablement le modifier pour lui envoyer toutes les combinaisons réussies de nom d'utilisateur et de mot de passe. S'il n'a pas accès au répertoire web, il peut toujours choisir un mot de passe, le hacher et l'écrire dans la base de données. En d'autres termes, l'algorithme de hachage n'est pas aussi important que la sécurité du système et la limitation des tentatives de connexion. De plus, si vous n'utilisez pas SSL, l'attaquant peut simplement écouter la connexion pour obtenir les informations. À moins que vous n'ayez besoin que l'algorithme prenne beaucoup de temps à calculer (pour vos propres besoins), alors SHA-256 ou SHA-512 avec un sel spécifique à l'utilisateur devrait suffire.

Comme mesure de sécurité supplémentaire, mettez en place un script (bash, batch, python, etc.) ou un programme et donnez-lui un nom obscur. Demandez-lui de vérifier si login.php a été modifié (vérifiez la date et l'heure) et de vous envoyer un e-mail si c'est le cas. Vous devriez aussi probablement enregistrer toutes les tentatives de connexion avec des droits d'administrateur et enregistrer toutes les tentatives échouées de connexion à la base de données et vous faire envoyer les journaux par courriel.