password_bcrypt Hash sécurisé et sel pour les mots de passe PHP




php hash password online (12)

Je tiens juste à souligner que PHP 5.5 inclut une API de hachage de mot de passe qui fournit un wrapper autour de crypt() . Cette API simplifie considérablement la tâche de hachage, de vérification et de ressassement des hachages de mots de passe. L'auteur a également publié un pack de compatibilité (sous la forme d'un seul fichier password.php que vous avez simplement require d'utiliser), pour ceux qui utilisent PHP 5.3.7 et les versions ultérieures et que vous souhaitez utiliser dès maintenant.

Il ne supporte que BCRYPT pour l'instant, mais il a pour but d'être facilement étendu pour inclure d'autres techniques de hachage de mot de passe et comme la technique et le coût sont stockés dans le hachage, les modifications de votre technique de hachage préférée n'invalideront pas les hachages actuels. utilisera automagiquement la bonne technique / coût lors de la validation. Il gère également la génération d'un sel "sécurisé" si vous ne définissez pas explicitement le vôtre.

L'API expose quatre fonctions:

  • password_get_info() - retourne des informations sur le hash donné
  • password_hash() - crée un mot de passe hash
  • password_needs_rehash() - vérifie si le hachage donné correspond aux options données. Utile pour vérifier si le hachage est conforme à votre schéma technique / coût actuel vous permettant de ressasser si nécessaire
  • password_verify() - vérifie qu'un mot de passe correspond à un hachage

Au moment où ces fonctions acceptent les constantes de mot de passe PASSWORD_BCRYPT et PASSWORD_DEFAULT, qui sont pour le moment, la différence étant que PASSWORD_DEFAULT "peut changer dans les nouvelles versions de PHP quand de nouveaux algorithmes de hachage plus forts sont supportés." L'utilisation de PASSWORD_DEFAULT et de password_needs_rehash () lors de la connexion (et du rehashing si nécessaire) devrait garantir que vos hachages sont raisonnablement résilients aux attaques par force brute avec peu ou pas de travail pour vous.

EDIT: Je viens de réaliser que cela est mentionné brièvement dans la réponse de Robert K. Je vais laisser cette réponse ici car je pense qu'elle fournit un peu plus d'informations sur son fonctionnement et la facilité d'utilisation qu'elle offre à ceux qui ne connaissent pas la sécurité.

On dit actuellement que MD5 est partiellement dangereux. En prenant cela en considération, j'aimerais savoir quel mécanisme utiliser pour la protection par mot de passe.

Cette question, est-ce que "double hashing" est un mot de passe moins sécurisé que juste le hacher une fois? suggère que le hachage à plusieurs reprises peut être une bonne idée, alors que Comment mettre en œuvre la protection par mot de passe pour les fichiers individuels? suggère d'utiliser du sel.

J'utilise PHP. Je veux un système de cryptage de mot de passe sûr et rapide. Hacher un mot de passe un million de fois peut être plus sûr, mais aussi plus lent. Comment atteindre un bon équilibre entre vitesse et sécurité? Aussi, je préférerais que le résultat ait un nombre constant de caractères.

  1. Le mécanisme de hachage doit être disponible en PHP
  2. Il doit être sûr
  3. Il peut utiliser du sel (dans ce cas, tous les sels sont-ils également bons? Y a-t-il un moyen de générer de bons sels?)

De même, devrais-je stocker deux champs dans la base de données (l'un utilisant MD5 et l'autre utilisant SHA, par exemple)? Serait-il plus sûr ou moins sûr?

Au cas où je n'étais pas assez clair, je veux savoir quelle (s) fonction (s) de hachage (s) utiliser et comment choisir un bon sel afin d'avoir un mécanisme de protection par mot de passe sûr et rapide.

Questions connexes qui ne couvrent pas tout à fait ma question:

Quelle est la différence entre SHA et MD5 en PHP
Chiffrement de mot de passe simple
Méthodes sécurisées de stockage des clés, mots de passe pour asp.net
Comment implémenteriez-vous des mots de passe salés dans Tomcat 5.5


J'ai trouvé un sujet parfait sur ce sujet ici: https://crackstation.net/hashing-security.htm , je voulais que vous en tiriez profit, voici aussi le code source qui fournissait également une prévention contre les attaques basées sur le temps.

<?php
/*
 * Password hashing with PBKDF2.
 * Author: havoc AT defuse.ca
 * www: https://defuse.ca/php-pbkdf2.htm
 */

// These constants may be changed without breaking existing hashes.
define("PBKDF2_HASH_ALGORITHM", "sha256");
define("PBKDF2_ITERATIONS", 1000);
define("PBKDF2_SALT_BYTES", 24);
define("PBKDF2_HASH_BYTES", 24);

define("HASH_SECTIONS", 4);
define("HASH_ALGORITHM_INDEX", 0);
define("HASH_ITERATION_INDEX", 1);
define("HASH_SALT_INDEX", 2);
define("HASH_PBKDF2_INDEX", 3);

function create_hash($password)
{
    // format: algorithm:iterations:salt:hash
    $salt = base64_encode(mcrypt_create_iv(PBKDF2_SALT_BYTES, MCRYPT_DEV_URANDOM));
    return PBKDF2_HASH_ALGORITHM . ":" . PBKDF2_ITERATIONS . ":" .  $salt . ":" . 
        base64_encode(pbkdf2(
            PBKDF2_HASH_ALGORITHM,
            $password,
            $salt,
            PBKDF2_ITERATIONS,
            PBKDF2_HASH_BYTES,
            true
        ));
}

function validate_password($password, $good_hash)
{
    $params = explode(":", $good_hash);
    if(count($params) < HASH_SECTIONS)
       return false; 
    $pbkdf2 = base64_decode($params[HASH_PBKDF2_INDEX]);
    return slow_equals(
        $pbkdf2,
        pbkdf2(
            $params[HASH_ALGORITHM_INDEX],
            $password,
            $params[HASH_SALT_INDEX],
            (int)$params[HASH_ITERATION_INDEX],
            strlen($pbkdf2),
            true
        )
    );
}

// Compares two strings $a and $b in length-constant time.
function slow_equals($a, $b)
{
    $diff = strlen($a) ^ strlen($b);
    for($i = 0; $i < strlen($a) && $i < strlen($b); $i++)
    {
        $diff |= ord($a[$i]) ^ ord($b[$i]);
    }
    return $diff === 0; 
}

/*
 * PBKDF2 key derivation function as defined by RSA's PKCS #5: https://www.ietf.org/rfc/rfc2898.txt
 * $algorithm - The hash algorithm to use. Recommended: SHA256
 * $password - The password.
 * $salt - A salt that is unique to the password.
 * $count - Iteration count. Higher is better, but slower. Recommended: At least 1000.
 * $key_length - The length of the derived key in bytes.
 * $raw_output - If true, the key is returned in raw binary format. Hex encoded otherwise.
 * Returns: A $key_length-byte key derived from the password and salt.
 *
 * Test vectors can be found here: https://www.ietf.org/rfc/rfc6070.txt
 *
 * This implementation of PBKDF2 was originally created by https://defuse.ca
 * With improvements by http://www.variations-of-shadow.com
 */
function pbkdf2($algorithm, $password, $salt, $count, $key_length, $raw_output = false)
{
    $algorithm = strtolower($algorithm);
    if(!in_array($algorithm, hash_algos(), true))
        die('PBKDF2 ERROR: Invalid hash algorithm.');
    if($count <= 0 || $key_length <= 0)
        die('PBKDF2 ERROR: Invalid parameters.');

    $hash_length = strlen(hash($algorithm, "", true));
    $block_count = ceil($key_length / $hash_length);

    $output = "";
    for($i = 1; $i <= $block_count; $i++) {
        // $i encoded as 4 bytes, big endian.
        $last = $salt . pack("N", $i);
        // first iteration
        $last = $xorsum = hash_hmac($algorithm, $last, $password, true);
        // perform the other $count - 1 iterations
        for ($j = 1; $j < $count; $j++) {
            $xorsum ^= ($last = hash_hmac($algorithm, $last, $password, true));
        }
        $output .= $xorsum;
    }

    if($raw_output)
        return substr($output, 0, $key_length);
    else
        return bin2hex(substr($output, 0, $key_length));
}
?>

Je ne stockerais pas le mot de passe haché de deux manières différentes, car alors le système est au moins aussi faible que le plus faible des algorithmes de hachage utilisés.


SHA1 and a salt should suffice (depending, naturally, on whether you are coding something for Fort Knox or a login system for your shopping list) for the foreseeable future. If SHA1 isn't good enough for you, use SHA256 .

The idea of a salt is to throw the hashing results off balance, so to say. It is known, for example, that the MD5-hash of an empty string is d41d8cd98f00b204e9800998ecf8427e . So, if someone with good enough a memory would see that hash and know that it's the hash of an empty string. But if the string is salted (say, with the string " MY_PERSONAL_SALT "), the hash for the 'empty string' (ie " MY_PERSONAL_SALT ") becomes aeac2612626724592271634fb14d3ea6 , hence non-obvious to backtrace. What I'm trying to say, that it's better to use any salt, than not to. Therefore, it's not too much of an importance to know which salt to use.

There are actually websites that do just this - you can feed it a (md5) hash, and it spits out a known plaintext that generates that particular hash. If you would get access to a database that stores plain md5-hashes, it would be trivial for you to enter the hash for the admin to such a service, and log in. But, if the passwords were salted, such a service would become ineffective.

Also, double-hashing is generally regarded as bad method, because it diminishes the result space. All popular hashes are fixed-length. Thus, you can have only a finite values of this fixed length, and the results become less varied. This could be regarded as another form of salting, but I wouldn't recommend it.


En fin de compte, le double-hachage, mathématiquement, ne fournit aucun avantage. En pratique, cependant, il est utile pour empêcher les attaques à base de tables arc-en-ciel. En d'autres termes, cela n'a pas plus d'intérêt que le hachage avec un sel, ce qui prend beaucoup moins de temps processeur dans votre application ou sur votre serveur.


Bien que la question ait été résolue, je veux juste réitérer que les sels utilisés pour le hachage devraient être aléatoires et ne pas être comme l'adresse e-mail comme suggéré dans la première réponse.

Plus d'explications sont disponibles sur http://www.pivotalsecurity.com/blog/password-hashing-salt-should-it-be-random/

Récemment j'ai eu une discussion pour savoir si les hashs salés avec des bits aléatoires sont plus sûrs que ceux qui sont salés avec des sels supposés ou connus. Voyons voir: Si le système stockant le mot de passe est compromis ainsi que le système qui stocke le sel aléatoire, l'attaquant aura accès au hachage ainsi qu'au sel, donc que le sel soit aléatoire ou non, peu importe. L'attaquant pourra générer des tables arc-en-ciel pré-calculées pour casser le hachage. Voici la partie intéressante - il n'est pas si trivial de générer des tables pré-calculées. Prenons l'exemple du modèle de sécurité WPA. Votre mot de passe WPA n'est en fait jamais envoyé au point d'accès sans fil. Au lieu de cela, il est haché avec votre SSID (le nom du réseau - comme Linksys, Dlink etc). Une très bonne explication de comment cela fonctionne est ici. Afin de récupérer le mot de passe de hash, vous aurez besoin de connaître le mot de passe ainsi que le sel (nom du réseau). Church of Wifi a déjà des tables de hachage pré-calculées qui ont 1000 premiers SSID et environ 1 million de mots de passe. La taille de toutes les tables est d'environ 40 Go. Comme vous pouvez le lire sur leur site, quelqu'un a utilisé 15 tableaux FGPA pendant 3 jours pour générer ces tableaux. En supposant que la victime utilise le SSID comme "a387csf3" et le mot de passe comme "123456", sera-t-il craqué par ces tables? Non! .. ça ne peut pas. Même si le mot de passe est faible, les tables n'ont pas de hash pour le SSID a387csf3. C'est la beauté d'avoir du sel au hasard. Cela dissuadera les craqueurs qui prospèrent sur des tables pré-calculées. Peut-il arrêter un hacker déterminé? Probablement pas. Mais en utilisant des sels aléatoires fournit une couche supplémentaire de défense. Alors que nous sommes sur ce sujet, laissez-nous discuter de l'avantage supplémentaire de stocker des sels aléatoires sur un système distinct. Scénario 1: Les hachages de mot de passe sont stockés sur le système X et les valeurs salées utilisées pour le hachage sont stockées sur le système Y. Ces valeurs de sel sont devinables ou connues (par exemple, nom d'utilisateur) Scénario 2: Les hachages sont stockés sur le système X le hachage est stocké sur le système Y. Ces valeurs de sel sont aléatoires. Dans le cas où le système X a été compromis, comme vous pouvez le deviner, il y a un énorme avantage à utiliser du sel aléatoire sur un système séparé (Scénario # 2). L'attaquant devra deviner les valeurs d'addition pour être capable de casser les hachages. Si un sel de 32 bits est utilisé, 2 ^ 32 = 4 294 967 296 (environ 4,2 milliards), des itérations pourront être requises pour chaque mot de passe deviné.


Une réponse beaucoup plus courte et plus sûre - n'écrivez pas votre propre mécanisme de mot de passe , utilisez un mécanisme éprouvé.

La plupart des programmeurs n'ont tout simplement pas l'expertise pour écrire du code crypto en toute sécurité sans introduire de vulnérabilités.

Auto-test rapide: qu'est-ce que l'étirement du mot de passe et combien d'itérations devriez-vous utiliser? Si vous ne connaissez pas la réponse, vous devriez utiliser password_hash() , car l'étirement du mot de passe est maintenant une caractéristique critique des mécanismes de mot de passe en raison de processeurs beaucoup plus rapides et de l'utilisation de GPUs et FPGAs pour cracker les mots de passe. (avec les GPU).

Par exemple, vous pouvez craquer tous les mots de passe Windows à 8 caractères en 6 heures en utilisant 25 GPU installés sur 5 ordinateurs de bureau. C'est un forçage brutal, c'est-à-dire l'énumération et la vérification de tous les mots de passe Windows à 8 caractères , y compris les caractères spéciaux, et ce n'est pas une attaque par dictionnaire. C'était en 2012, à partir de 2018, vous pourriez utiliser moins de GPU, ou craquer plus vite avec 25 GPU.

Il y a aussi de nombreuses attaques de tables arc-en-ciel sur les mots de passe Windows qui s'exécutent sur des processeurs ordinaires et qui sont très rapides. Tout cela est dû au fait que Windows ne salit pas encore et n'explose pas ses mots de passe, même dans Windows 10 - ne faites pas la même erreur que Microsoft!

Voir également:

  • excellente réponse avec plus sur pourquoi password_hash() ou phpass sont la meilleure voie à suivre.
  • bon article de blog donnant des 'facteurs de travail' recommandés (nombre d'itérations) pour les algorithmes principaux incluant bcrypt, scrypt et PBKDF2.

Depuis PHP 5.5, PHP dispose de fonctions simples et sécurisées pour le hachage et la vérification des mots de passe, php.net/manual/en/function.password-hash.php et password_verify

$password = 'anna';
$hash = password_hash($password, PASSWORD_DEFAULT);
$expensiveHash = password_hash($password, PASSWORD_DEFAULT, array('cost' => 20));

password_verify('anna', $hash); //Returns true
password_verify('anna', $expensiveHash); //Also returns true
password_verify('elsa', $hash); //Returns false

Quand password_hash() est utilisé, il génère un salt aléatoire et l'inclut dans le hachage outputted (avec le coût et l'algorithme utilisés) password_verify() lit ensuite ce hash et détermine la méthode de salt et de cryptage utilisée, et le vérifie par le mot de passe en clair fourni.

Fournir PASSWORD_DEFAULT demande à PHP d'utiliser l'algorithme de hachage par défaut de la version installée de PHP. Quel algorithme précis cela signifie est destiné à changer au fil du temps dans les versions futures, de sorte qu'il sera toujours l'un des algorithmes les plus forts disponibles.

L'augmentation du coût (qui vaut par défaut 10) rend le hachage plus difficile à force brute mais signifie également générer des hachages et vérifier les mots de passe contre eux, ce qui sera plus de travail pour le processeur de votre serveur.

Notez que même si l'algorithme de hachage par défaut peut changer, les anciens hachages continueront à se vérifier car l'algorithme utilisé est stocké dans le hachage et password_verify() récupère.


ok in the fitsy we need salt salt must be unique so let generate it

   /**
     * Generating string
     * @param $size
     * @return string
     */
    function Uniwur_string($size){
        $text = md5(uniqid(rand(), TRUE));
        RETURN substr($text, 0, $size);
    }

also we need the hash I`m using sha512 it is the best and it is in php

   /**
     * Hashing string
     * @param $string
     * @return string
     */
    function hash($string){
        return hash('sha512', $string);
    }

so now we can use this functions to generate safe password

// generating unique password
$password = Uniwur_string(20); // or you can add manual password
// generating 32 character salt
$salt = Uniwur_string(32);
// now we can manipulate this informations

// hashin salt for safe
$hash_salt = hash($salt);
// hashing password
$hash_psw = hash($password.$hash_salt);

now we need to save in database our $hash_psw variable value and $salt variable

and for authorize we will use same steps...

it is the best way to safe our clients passwords...

Ps for last 2 steps you can use your own algorithm... but be sure that you can generate this hashed password in the future when you need to authorize user...


CHOSES DONT IL FAUT SE RAPPELER

On a beaucoup parlé du cryptage des mots de passe pour PHP, dont la plupart sont de très bons conseils, mais avant même de commencer à utiliser PHP pour le cryptage des mots de passe, assurez-vous d'avoir implémenté ou prêt à être implémenté.

SERVEUR

PORTS

Peu importe la qualité de votre cryptage si vous ne sécurisez pas correctement le serveur qui exécute PHP et DB, tous vos efforts sont sans valeur. La plupart des serveurs fonctionnent relativement de la même manière, ils ont des ports assignés pour vous permettre d'y accéder à distance via ftp ou shell. Assurez-vous de changer le port par défaut de la connexion à distance que vous avez active. En ne faisant pas cela, vous avez en fait obligé l'attaquant à faire un pas de moins dans l'accès à votre système.

NOM D'UTILISATEUR

Pour tout ce qui est bon dans le monde n'utilisez pas le nom d'utilisateur admin, root ou quelque chose de similaire. De plus, si vous utilisez un système basé sur UNIX, NE RENDEZ PAS le login du compte root, il devrait toujours être sudo.

MOT DE PASSE

Vous dites à vos utilisateurs de faire de bons mots de passe pour éviter de se faire pirater, faites de même. Quel est le point en faisant tous les efforts de verrouillage de votre porte d'entrée lorsque vous avez la porte arrière grande ouverte.

BASE DE DONNÉES

SERVEUR

Idéalement, vous voulez votre base de données et votre application sur des serveurs séparés. Ce n'est pas toujours possible en raison du coût, mais cela permet une certaine sécurité car l'attaquant devra franchir deux étapes pour accéder au système.

UTILISATEUR

Faites en sorte que votre application dispose toujours de son propre compte pour accéder à la base de données et ne lui donne que les privilèges dont elle aura besoin.

Ayez alors pour vous un compte d'utilisateur distinct qui n'est stocké nulle part sur le serveur, même dans l'application.

Comme toujours NE FAITES PAS cette racine ou quelque chose de similaire.

MOT DE PASSE

Suivez les mêmes directives que pour tous les bons mots de passe. Ne réutilisez pas le même mot de passe sur des comptes SERVER ou DB sur le même système.

PHP

MOT DE PASSE

Ne jamais stocker un mot de passe dans votre base de données, à la place de stocker le hachage et le sel unique, je vais vous expliquer pourquoi plus tard.

HACHER

HASHING ONE WAY !!!!!!!, Jamais hash un mot de passe d'une manière qui peut être inversée, Hashes doit être à sens unique, ce qui signifie que vous ne les inversez pas et les comparer au mot de passe, vous hachez plutôt le mot de passe entré de la même manière et comparez les deux hachages. Cela signifie que même si un attaquant a accès à la base de données, il ne sait pas quel est le mot de passe, juste le hash qui en résulte. Ce qui signifie plus de sécurité pour vos utilisateurs dans le pire des cas.

Il y a beaucoup de bonnes fonctions de hachage ( password_hash , hash , etc ...) mais vous devez sélectionner un bon algorithme pour que le hachage soit efficace. (bcrypt et ceux qui lui ressemblent sont des algorithmes décents.)

Lorsque la vitesse de hachage est la clé, la plus lente est la plus résistante aux attaques de force brute.

L'une des erreurs les plus courantes dans le hachage est que les hachages ne sont pas uniques aux utilisateurs. C'est principalement parce que les sels ne sont pas générés de manière unique.

SALAISON

Les mots de passe doivent toujours être salés avant d'être hachés. Salting ajoute une chaîne aléatoire au mot de passe afin que les mots de passe similaires n'apparaissent pas identiques dans la base de données. Toutefois, si le sel n'est pas propre à chaque utilisateur (c'est-à-dire que vous utilisez un sel codé en dur), vous n'avez pratiquement pas fait de sel. Parce qu'une fois qu'un attaquant trouve un mot de passe, il a le sel pour chacun d'entre eux.

Lorsque vous créez un sel, assurez-vous qu'il est unique au mot de passe qu'il salage, puis stockez le hachage et le sel dans votre base de données. Ce que cela fera, c'est de faire en sorte qu'un attaquant devra cracker chaque sel et chaque hash avant de pouvoir y accéder. Cela signifie beaucoup plus de travail et de temps pour l'attaquant.

UTILISATEURS CRÉANT DES MOTS DE PASSE

Si l'utilisateur crée un mot de passe via le frontal, cela signifie qu'il doit être envoyé au serveur. Cela ouvre un problème de sécurité, car cela signifie que le mot de passe non crypté est envoyé au serveur et si un attaquant est capable d'écouter et d'accéder, toute votre sécurité en PHP est sans valeur. TOUJOURS transmettre les données en toute sécurité, ceci est fait via SSL, mais soyez fatigué même SSL n'est pas parfait (la faille Heartbleed d'OpenSSL en est un exemple).

De plus, faites en sorte que l'utilisateur crée un mot de passe sécurisé, c'est simple et doit toujours être fait, l'utilisateur sera reconnaissant à la fin.

Enfin, peu importe les mesures de sécurité que vous prenez, rien n'est sûr à 100%. Plus la technologie à protéger est avancée, plus les attaques deviennent avancées. Mais suivre ces étapes rendra votre site plus sûr et moins souhaitable pour les attaquants.

Voici une classe PHP qui crée un hachage et du sel pour un mot de passe facilement

http://git.io/mSJqpw


DISCLAIMER : Cette réponse a été écrite en 2008.

Depuis lors, PHP nous a donné php.net/manual/en/function.password-hash.php et password_verify et, depuis leur introduction, ils sont la méthode de hachage et de vérification de mot de passe recommandée.

La théorie de la réponse est encore une bonne lecture cependant.

TL; DR

Ne pas faire

  • Ne limitez pas les caractères que les utilisateurs peuvent entrer pour les mots de passe. Seuls les idiots le font.
  • Ne limitez pas la longueur d'un mot de passe. Si vos utilisateurs veulent une phrase avec supercalifragilisticexpialidocious, ne les empêchez pas de l'utiliser.
  • Ne stockez jamais le mot de passe de votre utilisateur en texte brut.
  • N'envoyez jamais de mot de passe à votre utilisateur, sauf s'il a perdu le sien et que vous lui avez envoyé un mot de passe temporaire.
  • Jamais, jamais enregistrer les mots de passe de quelque manière que ce soit.
  • Jamais hash mots de passe avec SHA1 ou MD5 ou même SHA256! Les craquelins modernes peuvent dépasser 60 et 180 milliards de hachages / seconde (respectivement).
  • Ne mélangez pas bcrypt et avec la sortie brute de hash () , utilisez soit la sortie hexadécimale, soit la base64_encode. (Ceci s'applique à toute entrée qui peut contenir un \0 , ce qui peut sérieusement affaiblir la sécurité.)

Dos

  • Utilisez scrypt quand vous le pouvez; bcrypt si vous ne pouvez pas.
  • Utilisez PBKDF2 si vous ne pouvez pas utiliser bcrypt ou scrypt, avec des hachages SHA2.
  • Réinitialiser les mots de passe de tout le monde lorsque la base de données est compromise.
  • Mettre en œuvre une longueur minimale raisonnable de 8 à 10 caractères, en plus d'exiger au moins une lettre majuscule, une lettre minuscule, un chiffre et un symbole. Cela améliorera l'entropie du mot de passe, ce qui le rendra plus difficile à déchiffrer. (Voir la section "Qu'est-ce qui fait un bon mot de passe?" Pour un débat.)

Pourquoi hacher les mots de passe quand même?

L'objectif derrière le hachage des mots de passe est simple: empêcher l'accès malveillant aux comptes d'utilisateurs en compromettant la base de données. Ainsi, l'objectif du hachage par mot de passe est de dissuader un pirate ou un pirate informatique en leur coûtant trop de temps ou d'argent pour calculer les mots de passe en texte brut. Et le temps / coût sont les meilleurs moyens de dissuasion dans votre arsenal.

Une autre raison pour laquelle vous voulez un bon hachage robuste sur un compte d'utilisateur est de vous donner assez de temps pour changer tous les mots de passe dans le système. Si votre base de données est compromise, vous aurez besoin de suffisamment de temps pour au moins verrouiller le système, sinon changer chaque mot de passe dans la base de données.

Jeremiah Grossman, CTO de Whitehat Security, a déclaré sur son blog après une récente récupération de mot de passe qui a nécessité une rupture brutale de sa protection par mot de passe:

Fait intéressant, en vivant ce cauchemar, j'ai appris BEAUCOUP que je ne savais pas sur le mot de passe cracking, le stockage et la complexité. J'ai appris à comprendre pourquoi le stockage de mot de passe est toujours plus important que la complexité du mot de passe. Si vous ne savez pas comment votre mot de passe est stocké, tout ce sur quoi vous pouvez réellement compter est la complexité. Cela peut être une connaissance courante du mot de passe et des professionnels de la crypto, mais pour l'expert InfoSec ou Web Security moyen, j'en doute fortement.

(Emphase la mienne.)

Qu'est-ce qui fait un bon mot de passe quand même?

Entropy (Pas que je souscris pleinement au point de vue de Randall.)

En bref, l'entropie est la quantité de variation dans le mot de passe. Quand un mot de passe est seulement en minuscules romaines, ce n'est que 26 caractères. Ce n'est pas beaucoup de variation. Les mots de passe alphanumériques sont meilleurs, avec 36 caractères. Mais autoriser les majuscules et minuscules, avec des symboles, est d'environ 96 caractères. C'est beaucoup mieux que des lettres. Un problème est que, pour rendre nos mots de passe mémorisables, nous insérons des motifs, ce qui réduit l'entropie. Oops!

L'entropie du mot de passe est approximated facilement. L'utilisation de la gamme complète de caractères ascii (environ 96 caractères typables) donne une entropie de 6,6 par caractère, ce qui à 8 caractères pour un mot de passe est encore trop faible (52,679 bits d'entropie) pour la sécurité future. Mais les bonnes nouvelles sont: des mots de passe plus longs, et des mots de passe avec des caractères Unicode, augmentent vraiment l'entropie d'un mot de passe et le rendent plus difficile à cracker.

Il y a une discussion plus longue sur l'entropie du mot de passe sur le site Crypto StackExchange . Une bonne recherche sur Google donnera aussi beaucoup de résultats.

Dans les commentaires j'ai parlé avec @popnoodles, qui a souligné que l' application d' une politique de mot de passe de X longueur avec X beaucoup de lettres, nombres, symboles, etc., peut effectivement réduire l'entropie en rendant le schéma de mot de passe plus prévisible. Je suis d'accord. Randomess, aussi aléatoire que possible, est toujours la solution la plus sûre mais la moins mémorable.

Autant que j'ai pu le dire, faire le meilleur mot de passe du monde est un Catch-22. Soit ce n'est pas mémorable, trop prévisible, trop court, trop de caractères Unicode (difficile à taper sur un appareil Windows / Mobile), trop long, etc. Aucun mot de passe n'est vraiment assez bon pour nos besoins, nous devons donc les protéger comme s'ils étaient à Fort Knox.

Les meilleures pratiques

Bcrypt et scrypt sont les meilleures pratiques actuelles. scrypt sera meilleur que bcrypt dans le temps, mais il n'a pas été adopté comme standard par Linux / Unix ou par les serveurs web, et n'a pas encore fait l'objet de critiques approfondies de son algorithme. Mais encore, l'avenir de l'algorithme semble prometteur. Si vous travaillez avec Ruby, il y a une gemme scrypt qui vous aidera, et Node.js a maintenant son propre paquet scrypt . Vous pouvez utiliser Scrypt en PHP via l'extension Scrypt ou l'extension Libsodium (les deux sont disponibles dans PECL).

Je suggère fortement de lire la documentation de la fonction crypt si vous voulez comprendre comment utiliser bcrypt, ou vous trouver un good wrapper ou utiliser quelque chose comme openwall.com/phpass pour une implémentation plus ancienne. Je recommande un minimum de 12 tours de bcrypt, sinon 15 à 18.

J'ai changé d'avis à propos de l'utilisation de bcrypt quand j'ai appris que bcrypt n'utilisait que la programmation clé de blowfish, avec un mécanisme de coût variable. Ce dernier vous permet d'augmenter le coût de la force brute d'un mot de passe en augmentant le programme clé déjà cher de blowfish.

Pratiques moyennes

Je ne peux presque plus imaginer cette situation. openwall.com/phpass supporte PHP 3.0.18 à 5.3, donc il est utilisable sur presque toutes les installations imaginables - et devrait être utilisé si vous ne savez pas avec certitude que votre environnement supporte bcrypt.

Mais supposons que vous ne puissiez pas utiliser bcrypt ou PHPASS. Quoi alors?

Essayez une implémentation de PDKBF2 avec le nombre maximum de tours que votre environnement / application / perception utilisateur peut tolérer. Le plus petit nombre que je recommanderais est 2500 tours. Assurez-vous également d'utiliser hash_hmac() s'il est disponible pour rendre l'opération plus difficile à reproduire.

Pratiques futures

Venir en PHP 5.5 est une bibliothèque complète de protection par mot de passe qui résout toute peine de travailler avec bcrypt. Alors que la plupart d'entre nous sont coincés avec PHP 5.2 et 5.3 dans les environnements les plus communs, en particulier les hôtes partagés, @ircmaxell a construit une couche de compatibilité pour l'API à venir qui est rétrocompatible avec PHP 5.3.7.

Récapitulatif de la cryptographie et avis de non-responsabilité

La puissance de calcul requise pour réellement cracker un mot de passe hashé n'existe pas. La seule façon pour les ordinateurs de "casser" un mot de passe est de le recréer et de simuler l'algorithme de hachage utilisé pour le sécuriser. La vitesse du hachage est liée linéairement à sa capacité à être brutalement forcé. Pire encore, la plupart des algorithmes de hachage peuvent être facilement parallélisés pour fonctionner encore plus rapidement. C'est pourquoi des systèmes coûteux comme bcrypt et scrypt sont si importants.

Vous ne pouvez pas prévoir toutes les menaces ou voies d'attaque, et vous devez donc faire de votre mieux pour protéger vos utilisateurs dès le départ . Si vous ne le faites pas, vous pourriez même manquer le fait que vous avez été attaqué jusqu'à ce qu'il soit trop tard ... et vous êtes responsable . Pour éviter cette situation, agissez paranoïaque pour commencer. Attaquez votre propre logiciel (en interne) et tentez de voler les informations d'identification de l'utilisateur, ou de modifier les comptes d'autres utilisateurs ou d'accéder à leurs données. Si vous ne testez pas la sécurité de votre système, vous ne pouvez pas blâmer qui que ce soit, sauf vous-même.

Enfin: je ne suis pas un cryptographe. Tout ce que j'ai dit est mon opinion, mais je pense que c'est basé sur le bon sens du bon sens ... et beaucoup de lecture. Rappelez-vous, soyez aussi paranoïaque que possible, faites en sorte que les choses soient aussi difficiles que possible, et si vous êtes encore inquiet, contactez un pirate ou un cryptographe pour voir ce qu'ils disent de votre code / système.


Google dit que SHA256 est disponible pour PHP.

Vous devriez certainement utiliser un sel. Je vous recommande d'utiliser des octets aléatoires (et ne vous limitez pas aux caractères et aux nombres). Comme d'habitude, plus vous choisissez, plus c'est sécuritaire et lent. 64 octets devraient être bien, je suppose.





protection