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

Je fais une connexion php et j'essaie de décider d'utiliser SHA1 ou Md5, ou SHA256 dont j'ai lu dans un autre article de stackoverflow. Certains d'entre eux sont-ils plus sûrs que d'autres? Pour SHA1 / 256, est-ce que j'utilise encore un sel?

De plus, est-ce un moyen sécurisé 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);

Ni. Vous devriez utiliser bcrypt. Les hachages que vous mentionnez sont tous optimisés pour être rapides et faciles sur le matériel, et ainsi les craquer partagent les mêmes qualités. Si vous n'avez pas d'autre choix, assurez-vous au moins d'utiliser un long sel et de re-hacher plusieurs fois.

Utilisation de bcrypt dans PHP 5.5+

PHP 5.5 offre de nouvelles fonctions pour le hachage des mots de passe . Il s'agit de l'approche recommandée pour le stockage des mots de passe dans les applications Web modernes.

// Creating a hash
$hash = password_hash($password, PASSWORD_DEFAULT, ['cost' => 12]);
// If you omit the ['cost' => 12] part, it will default to 10

// Verifying the password against the stored hash  
if (password_verify($password, $hash)) {
    // Success! Log the user in here.
}

Si vous utilisez une ancienne version de PHP, vous devriez vraiment mettre à jour , mais jusqu'à ce que vous le fassiez, vous pouvez utiliser password_compat pour exposer cette API.

Aussi, laissez password_hash()générer le sel pour vous. Il utilise un CSPRNG .

Deux mises en garde de bcrypt

1. Bcrypt tronquera silencieusement tout mot de passe de plus de 72 caractères.
2. Bcrypt tronquera après tous les NULcaractères.

( Preuve de concept pour les deux mises en garde ici.)

Vous pourriez être tenté de résoudre la première mise en garde en pré-hachant vos mots de passe avant de les exécuter via bcrypt , mais cela peut entraîner l'exécution de votre application tête première dans le second.

Au lieu d'écrire votre propre schéma, utilisez une bibliothèque existante écrite et / ou évaluée par des experts en sécurité.

• Zend\Crypt (fait partie de Zend Framework) offre BcryptSha
• PasswordLockest similaire à BcryptShamais il crypte également les hachages bcrypt avec une bibliothèque de cryptage authentifiée .

TL; DR - Utilisez bcrypt .

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

1. Si vous autorisez les utilisateurs à utiliser des mots de passe faibles tels que Dieu, amour, guerre, paix, 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, donc cela ne va PAS avoir quoi que ce soit à 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 pourront extraire le mot de passe et toute tentative de chiffrement avec javascript ou autre est côté client et est facilement craquelée et surmontée. Encore une fois, cela n'aura rien à voir avec le cryptage des données côté serveur.

3. Brutes attaques de force prendront avantage mots de passe faibles et encore parce que vous permettez à l'utilisateur d'entrer les données si vous ne disposez pas de la limitation de connexion de 3 ou même un peu plus le problème sera à nouveau pas avoir quelque chose à voir avec le cryptage des données.

4. Si votre base de données est compromise, il est fort probable que tout a été compromis, y compris vos techniques de hachage, peu importe à quel point vous l'avez fait. Encore une fois, cela pourrait être une attaque XSS d'employé mécontent ou une injection SQL ou une autre attaque qui n'a rien à voir avec le cryptage de votre mot de passe.

Je pense que vous devriez toujours crypter, mais la seule chose que je peux voir que le cryptage fait est d'empêcher les personnes qui ont déjà ou ont accédé à la base de données de simplement lire à haute voix le mot de passe. S'il s'agit d'une personne non autorisée dans la base de données, vous avez de plus gros problèmes à craindre, c'est pourquoi Sony a été pris parce qu'ils pensaient qu'un mot de passe crypté protégeait tout, y compris les numéros de carte de crédit, tout ce qu'il fait est de protéger ce champ.

Le seul avantage pur que je peux voir aux cryptages complexes des mots de passe dans une base de données est de retarder les employés ou d'autres personnes qui ont accès à la base de données de simplement lire les mots de passe. Donc, s'il s'agit d'un petit projet ou de quelque chose, je ne m'inquiéterais pas trop de la sécurité côté serveur à la place, je m'inquiéterais davantage de la sécurité de tout ce qu'un client pourrait envoyer au serveur, comme l'injection SQL, les attaques XSS ou la pléthore d'autres moyens que vous pourrait être compromis. Si quelqu'un n'est pas d'accord, j'ai hâte de lire une façon qu'un mot de passe super crypté est un must du côté client.

La raison pour laquelle je voulais essayer de clarifier cela est que trop souvent les gens croient 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écurité du site Web.

Comme l'a souligné Johannes Gorset, l'article de Thomas Ptacek de Matasano Security explique pourquoi les fonctions de hachage simples et polyvalentes telles que MD5, SHA1, SHA256 et SHA512 sont de mauvais choix de hachage de mot de passe .

Pourquoi? Ils sont trop rapides - vous pouvez calculer au moins 1 000 000 de hachages MD5 par seconde par cœur avec un ordinateur moderne, la force brute est donc possible contre la plupart des mots de passe utilisés. Et c'est bien moins qu'un cluster de serveurs de craquage basé sur GPU!

Le salage sans étirement des touches signifie uniquement 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 compliquera pas vraiment les choses.

L'utilisateur @ Will dit:

Tout le monde en parle comme s'il pouvait être piraté sur Internet. Comme déjà indiqué, limiter les tentatives rend impossible de déchiffrer 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é la vulnérabilité commune d' injection SQL pour obtenir la table de base de données de connexion et déchiffré 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 toute la base de données est compromise et qu'un hacker peut alors effectuer 100 millions de tentatives de mot de passe par seconde contre le hachage md5. SHA512 est environ 10 000 fois plus lent.

Non, SHA512 n'est pas 10000 fois plus lent que MD5 - il n'en faut qu'environ deux fois plus. Crypt / SHA512 , d'autre part, est une bête très différente qui, comme son homologue BCrypt, effectue un étirement de clé , produisant un hachage très différent avec un sel aléatoire intégré et prendra entre 500 et 999999 fois plus pour calculer (l'étirement est réglable).

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

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

Utilisez SHA256. Ce n'est pas parfait, comme ce SHA512serait idéal pour un hachage rapide, mais parmi les options, c'est le choix définitif. Comme pour toute technologie de hachage, assurez-vous de saler le hachage pour plus de sécurité.

Comme note supplémentaire, FRKT, s'il vous plaît, montrez-moi où quelqu'un peut facilement casser un hachage SHA256 salé? Je suis vraiment très intéressé de voir cela.

Modification importante:

À l'avenir, veuillez l'utiliser bcryptcomme un hachage renforcé. Plus d'informations peuvent être trouvées ici .

Modifier sur le salage:

Utilisez un nombre aléatoire ou un flux d'octets aléatoire, 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.

Ce que les gens semblent manquer, c'est que si le pirate a accès à la base de données, il a probablement également accès au fichier php qui hache le mot de passe et peut probablement simplement le modifier pour lui envoyer tous les combos de mots de passe de nom d'utilisateur réussis. S'il n'a pas accès au répertoire Web, il peut toujours simplement choisir un mot de passe haché et l'écrire dans la base de données. En d'autres termes, l'algorithme de hachage n'a pas vraiment autant d'importance que la sécurité du système, et en limitant les tentatives de connexion également 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), SHA-256 ou SHA-512 avec un sel spécifique à l'utilisateur devrait suffire.

Comme mesure de sécurité supplémentaire, configurez un script (bash, batch, python, etc.) ou un programme et donnez-lui un nom obscur et demandez-lui de vérifier et de voir si login.php a changé (vérifier la date / heure) et vous envoyer un e-mail si c'est le cas. Il devrait également probablement enregistrer toutes les tentatives de connexion avec les droits d'administrateur et enregistrer toutes les tentatives infructueuses de connexion à la base de données et vous envoyer les journaux par courrier électronique.

Tout le monde en parle comme s'il pouvait être piraté sur Internet. Comme déjà indiqué, limiter les tentatives rend impossible de déchiffrer un mot de passe sur Internet et n'a rien à voir avec le hachage.

Le sel est un must, mais la complexité ou les multiples sels n'ont même pas d'importance. Tout sel seul empêche l'attaquant d'utiliser une table arc-en-ciel préfabriquée. Un sel unique par utilisateur empêche l'attaquant de créer une nouvelle table arc-en-ciel à utiliser contre l'ensemble de votre base d'utilisateurs.

La sécurité entre vraiment en jeu lorsque toute la base de données est compromise et qu'un hacker peut alors effectuer 100 millions de tentatives de mot de passe par seconde contre le hachage md5. SHA512 est environ 10 000 fois plus lent. Un mot de passe complexe avec la puissance d'aujourd'hui pourrait encore prendre 100 ans à bruteforce avec md5 et prendrait 10 000 fois plus de temps avec SHA512. Les sels n'arrêtent pas du tout une force brute car ils doivent toujours être connus, ce qui si l'attaquant téléchargeait votre base de données, il était probablement dans votre système de toute façon.

MD5 est mauvais en raison de problèmes de collision - deux mots de passe différents générant peut-être le même md-5.

Sha-1 serait très sûr pour cela. La raison pour laquelle vous stockez la version sha-1 salée du mot de passe est que vous, le swerver, ne gardez pas le mot de passe de l'utilisateur dans un fichier, qu'il peut utiliser avec les serveurs d'autres personnes. Sinon, quelle différence cela fait-il?

Si le pirate vole toute votre base de données non chiffrée d'une manière ou d'une autre, la seule chose qu'un mot de passe haché salé fait est de l'empêcher de se faire passer pour l'utilisateur pour les futurs codes d'accès - le pirate a déjà les données.

À quoi sert l'attaquant d'avoir la valeur hachée, si ce que votre utilisateur saisit est un mot de passe simple?

Et même si le pirate avec la technologie future pouvait générer un million de clés sha-1 par seconde pour une attaque par force brute, votre serveur traiterait-il un million de connexions par seconde pour que le pirate teste ses clés? C'est si vous laissez le pirate essayer de se connecter avec le sha-1 salé au lieu d'un mot de passe comme une connexion normale.

Le mieux est de limiter les mauvaises tentatives de connexion à un nombre raisonnable - 25 par exemple, puis d'exclure l'utilisateur pendant une minute ou deux. Et si les tentatives de connexion bady cumulées atteignent 250 dans les 24 heures, fermez l'accès au compte et envoyez un e-mail au propriétaire.

Voici la comparaison entre MD5 et SHA1. Vous pouvez avoir une idée claire de celui qui est le meilleur.

Utilisez argon2i . L' argon2 fonction de hachage de mot de passe a remporté le concours de hachage de mot de passe.

D'autres choix raisonnables, si l'utilisation d' argon2 n'est pas disponible, sont scrypt , bcrypt et PBKDF2 . Wikipedia a des pages pour ces fonctions:

• https://en.wikipedia.org/wiki/Argon2
• http://en.wikipedia.org/wiki/Scrypt
• http://en.wikipedia.org/wiki/Bcrypt
• http://en.wikipedia.org/wiki/PBKDF2

MD5, SHA1 et SHA256 sont des résumés de messages et non des fonctions de hachage de mot de passe. Ils ne conviennent pas à cet effet.

Le passage de MD5 à SHA1 ou SHA512 n'améliorera pas tant la sécurité de la construction. Le calcul d'un hachage SHA256 ou SHA512 est très rapide. Un attaquant avec un matériel commun pourrait toujours essayer des dizaines de millions (avec un seul processeur) ou même des milliards (avec un seul GPU) de hachages par seconde. De bonnes fonctions de hachage de mot de passe incluent un facteur de travail pour ralentir les attaques par dictionnaire.

Voici une suggestion pour les programmeurs PHP: lisez la FAQ PHP puis utilisez password_hash () .

Supposons le point suivant: les pirates volent notre base de données, y compris les utilisateurs et le mot de passe (crypté). Et les pirates ont créé un faux compte avec un mot de passe qu'ils connaissent.

MD5 est faible car sa génération courte et populaire et pratiquement chaque génération de hachage sans mot de passe est faible d'une attaque par dictionnaire. Mais..

Alors, disons que nous utilisons toujours MD5 avec un SALT. Les hackers ne connaissent pas le SALT mais ils connaissent le mot de passe d'un utilisateur spécifique. Ainsi, ils peuvent tester: ????? 12345 où 12345 est le mot de passe connu et ????? est le sel. Les hackers peuvent tôt ou tard deviner le SALT.

Cependant, si nous avons utilisé un MD5 + SALT et que nous avons appliqué MD5, il n'y a aucun moyen de récupérer les informations. Cependant, je le répète, MD5 est encore court.

Par exemple, disons que mon mot de passe est: 12345. Le SALT est BILLCLINTON

md5: 827ccb0eea8a706c4c34a16891f84e7b

md5 avec le hash: 56adb0f19ac0fb50194c312d49b15378

mD5 avec le hachage sur md5: 28a03c0bc950decdd9ee362907d1798a J'ai essayé d'utiliser ces services en ligne et je n'en ai trouvé aucun capable de le casser. Et son seul MD5! (peut-être comme aujourd'hui, il sera craquelable car j'ai généré le md5 en ligne)

Si vous voulez exagérer, SHA256 est plus que suffisant s'il est appliqué avec du sel et deux fois.

tldr MD5 (HASH + MD5 (mot de passe)) = ok mais bref, SHA256 est plus que suffisant.

Un cryptage md5 est l'un des pires, car il faut tourner le code et il est déjà décrypté. Je vous recommanderais le SHA256. Je programme un peu plus longtemps et j'ai eu une bonne expérience. Ci-dessous serait également un cryptage.

password_hash() example using Argon2i

<?php
echo 'Argon2i hash: ' . password_hash('rasmuslerdorf', PASSWORD_ARGON2I);
?>
The above example will output something similar to:

Argon2i hash: $argon2i$v=19$m=1024,t=2,p=2$YzJBSzV4TUhkMzc3d3laeg$zqU/1IN0/AogfP4cmSJI1vc8lpXRW9/S0sYY2i2jHT0