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


133

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);


Consultez également cette réponse et lisez la section sur le hachage de mot de passe.
Ja͢ck

Réponses:


110

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é.

TL; DR - Utilisez bcrypt .


1
aussi, je suis très nouveau dans ce domaine: sha1, sha256 et md5 sont-ils tous les «hachages» auxquels vous faites référence?
Tony Stark

3
Oui. Je fais référence à SHA1, SHA256 et MD5 et à une série d'autres hachages optimisés pour la vitesse. Vous ne voulez pas utiliser un hachage optimisé pour la vitesse pour sécuriser un mot de passe. Il y a beaucoup de bons articles expliquant pourquoi, et j'aime celui-ci en particulier: chargen.matasano.com/chargen/2007/9/7/…
Johannes Gorset

4
Il est inclus dans la fonction "crypt" depuis PHP 5.3. Si vous avez une version antérieure, je regarderais dans le framework "phpass" pour la meilleure chose suivante.
Johannes Gorset

3
@Stanislav Palatnik SHA512 est une bonne alternative. Ne vous méprenez pas; Je ne dis pas qu'un hachage SHA512 étiré et salé n'est pas sécurisé. C'est sécurisé. Même ainsi, il n'en reste pas moins que bcrypt est plus sécurisé et je ne vois donc aucune raison de ne pas l'utiliser.
Johannes Gorset

10
@Cypher: bcryptest conçu pour être lent dans l'intérêt d'être également lent à craquer.
Johannes Gorset

23

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.


1
Bien énoncé. La cybersécurité doit être préférée aux techniques de hachage, elles sauvegardent non seulement vos données, mais gardent également la défense du serveur prête.
CᴴᴀZ

14
C'est vraiment mal informé. Bien sûr, le hachage sécurisé des mots de passe dans la base de données n'améliore pas la sécurité au niveau de l'application ou de la base de données. Ce n'est pas un fourre-tout pour la sécurité. Vous souhaitez hacher en toute sécurité le mot de passe utilisateur dans votre base de données pour 2 raisons; tout d'abord, le client vous fait confiance avec son mot de passe, qu'il peut ou non utiliser sur d'autres sites, vous voulez donc vous assurer que ce n'est pas récupérable, même si votre db est compromise, deuxièmement, vous souhaitez supprimer la responsabilité en cas de sécurité violation. Je ne connais pas de poursuites judiciaires, mais la fuite de mots de passe donne à votre entreprise une très mauvaise apparence.
James McMahon

6
C'est un mauvais conseil. Si quelqu'un vole votre base de données et obtient tous vos mots de passe hachés, même s'il a également compromis d'autres parties de votre base de données, il peut toujours être important de l'empêcher de déchiffrer les mots de passe et de se connecter. (Pensez à un site Web bancaire, par exemple.) Des algorithmes à vitesse optimisée permettent aux attaquants de tester de nombreux candidats contre les hachages volés jusqu'à ce qu'ils trouvent une correspondance. Des algorithmes comme bcrypt et scrypt rendent le test des candidats lent et coûteux contre le hachage, même s'ils savent quel algorithme vous utilisez. Ils offrent donc une meilleure protection si quelqu'un vole les hachages.
Richard

6
"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 rendu cryptique." C'est pourquoi bcrypt est si important. Avec bcrypt, peu importe si quelqu'un a les hachages. Avec un algorithme de hachage rapide comme SHA1 / MD5, c'est le cas.
ceejayoz

Je pense que le point qui manque à certains d'entre vous, c'est que peu importe si le mot de passe est sécurisé à 1000% lorsque toutes les autres données sont en texte clair. Par exemple, si toute la base de données est compromise, le pirate informatique dispose désormais de tous les numéros de carte de crédit en texte clair. Oui, beaucoup de gens utilisent le même mot de passe sur différents sites Web, mais on leur a déjà dit ad nauseum de ne pas le faire, donc ce n'est plus notre problème. Si la base de données elle-même contient des informations sensibles et que sa compromission est un problème, chiffrez l'ensemble de la base de données, aussi fortement que vous le jugez nécessaire.
UncaAlby

15

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


Le hachage de mot de passe simple est très bien, c'est au pare-feu de garder le serveur en sécurité .. et par «pare-feu», j'entends un pare-feu réactif qui bloque / ralentit la force brute (un humain ne peut taper QUE RAPIDEMENT) .. ce le concours est inutile .. .. "et si un pirate a fait irruption et a maintenant tout" (face-desk) - si un pirate a pénétré dans votre serveur - c'est fini. Les mots de passe sont piratés principalement parce qu'ils sont trop simples ou que les développeurs de logiciels sont trop paresseux pour penser comme un cyber-criminel.

@argon Veuillez lire à nouveau. Le but du hachage des mots de passe est de faire en sorte que lorsque votre base de données de connexion est compromise (et cela le fera à un moment donné), vous ne divulguez pas immédiatement tous les mots de passe de vos utilisateurs, qui sont le plus souvent réutilisés par les utilisateurs sur différents sites. un délai après l'entrée ferait l'affaire. Et le "jeu terminé s'ils sont entrés dans votre serveur" est un point discutable, car ils n'ont pas besoin d'entrer dans votre serveur. La vulnérabilité la plus couramment utilisée par les pirates informatiques a été l'injection SQL (voir le cas Linkedin), puis ils force brutalement le hachage. C'est pourquoi vous avez besoin de salage et d'étirement.
LexLythius

si l'exigence de sécurité est vraiment si intense, alors stocker les mots de passe ailleurs peut être une bonne idée. Il existe de nombreuses façons de protéger vos données (et votre code source) -pour "si / quand" ... .. -mais le hachage des mots de passe jusqu'à un "milliard de bits" n'est aussi sûr que: le créateur de mot de passe / système invité , la transmission de données et les humains qui entretiennent le matériel du serveur. .. cela étant dit: je ne dis PAS que le hachage est inutile, mais je dis que si votre solution est simplement des hachages plus compliqués, j'ai peur que cela ne fonctionnera pas dans un proche avenir, en ce qui concerne les ordinateurs quantiques.

Le hachage récursif ajoute du travail / coût à toute tentative de piratage. Plus il y a d'itérations, plus il est difficile de craquer, donc même des hachages rapides comme SHA256 pourraient être utilisés. Les itérations doivent être aléatoires et peuvent être rendues publiques. password_hash()montre le coût dans le hachage lui-même.
Victor Stoddard

@VictorStoddard Oui, vous pouvez rouler votre propre schéma de hachage et fournir un étirement de clé réglable. Mais pourquoi voulez - vous voulez faire cela au lieu d'utiliser déjà existants, des algorithmes beaucoup plus que les experts examinent minutieusement ont créé et mis à disposition dans ce but précis?
LexLythius

13

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.


1
Mais ils sont optimisés pour la vitesse, ce qui signifie qu'ils permettent le piratage par force brute.
arbales

6
Le fait demeure, il s'agit de sécuriser un mot de passe. En utilisant un hachage avec un sel, puis en ajoutant une limite de 3 tentatives sur le site Web, vous ralentissez considérablement les tentatives des pirates (même les forceurs bruts). En utilisant n'importe quel cryptage pur, vous avez maintenant un autre problème: la sécurisation de la clé. Si la clé est trouvée, toute votre base de données est compromise (si aucun sel n'est ajouté). Les hachages cependant, vous n'obtiendrez jamais le mot de passe d'origine du système, et c'est ainsi qu'il devrait être.
Kyle Rosendo

1
Comme indiqué, le problème avec les séries MD et SHA est qu'elles sont optimisées pour la vitesse. Il est inévitable que les hachages de cette nature deviennent de plus en plus incertains à mesure que l'informatique évolue.
Johannes Gorset

1
Tout devient de plus en plus mauvais / peu sûr / etc à mesure que l'informatique évolue. Au moment où SHA512 etc. seront piratés, des algorithmes plus sécurisés seront disponibles. C'est de toute façon la nature de l'informatique.
Kyle Rosendo

1
quel est un bon moyen de faire un sel en php? avoir un exemple de code? J'imagine que je ne devrais pas simplement choisir quelque chose comme `` girafe ''
Tony Stark

4

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.


"Ce que les gens semblent manquer, 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 ..." Ce n'est pas vrai. L'une des vulnérabilités les plus courantes est l'injection SQL, qui donnerait une capacité de lecture / écriture à la base de données mais aucun accès au code PHP.
ceejayoz

Si vous avez accès au code, vous pouvez modifier et stocker tout le mot de passe que l'utilisateur envoie en texte brut. Donc non, si le code est compromis, GAME OVER.
magallanes

3

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.


1

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.


Même si j'utilise un cryptage plus faible, pratiquement aucun système ne peut contenir une attaque brute pendant plus d'un million d'essais par seconde.
magallanes le

1
Trois échecs de connexion et vous êtes bloqué. Période, fin de l'histoire. Même les mots de passe super stupides comme "1234" sont sécurisés, si le pirate essaie d'abord "password", "pa $$ word" et "passw0rd" (lock-out!). La façon dont l'utilisateur retrouve l'accès devient maintenant votre point de blocage de la sécurité, et ce que vous faites dépend de la taille de votre base d'utilisateurs. 200 utilisateurs? Demandez-leur de téléphoner pour obtenir de l'aide.
UncaAlby

Cette réponse n'a-t-elle aucun sens pour quelqu'un d'autre ou est-ce juste moi?
Wildcard

1

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

entrez la description de l'image ici


1

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:

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 () .


0

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.


Le problème avec l'utilisation de MD5 avec un sel est que les ordinateurs peuvent créer une attaque par force brute sur le mot de passe unique avec des vitesses ultra rapides. shylor.com/2015/09/14/php-5-5-secure-password-hashing
Shylor

0

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
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.