Le hash de session est-il important?

Question

La taille est-elle importante lors du choix du bon algorithme à utiliser pour un hachage de session?

J'ai récemment lu ceci article et il a suggéré d'utiliser whirlpool pour créer un hachage pour l'identifiant de session. Whirlpool génère une chaîne de hachage de 128 caractères, est-ce trop grand?

Le plan est de stocker le hachage de session dans un db. Y a-t-il une grande différence entre utiliser un champ de 64 caractères (sha256), un champ de 96 caractères (sha384) ou un champ de 128 caractères (whirlpool)? L'un des arguments initiaux avancés pour whirlpool était la vitesse par rapport à d'autres algorithmes, mais en regardant les résultats de vitesse, sha384 ne va pas trop mal.

Il y a l'option tronquer le hachage pour le rendre plus petit que 128 caractères.

J'ai modifié l'extrait de code original, pour permettre le changement de l'algorithme en fonction des besoins.

Mise à jour: Il y a eu une discussion à propos de la chaîne en cours de hachage, donc j'ai inclus le code.

function generateUniqueId($maxLength = null) { 
    $entropy = ''; 

    // try ssl first 
    if (function_exists('openssl_random_pseudo_bytes')) { 
     $entropy = openssl_random_pseudo_bytes(64, $strong); 
     // skip ssl since it wasn't using the strong algo 
     if($strong !== true) { 
      $entropy = ''; 
     } 
    } 

    // add some basic mt_rand/uniqid combo 
    $entropy .= uniqid(mt_rand(), true); 

    // try to read from the windows RNG 
    if (class_exists('COM')) { 
     try { 
      $com = new COM('CAPICOM.Utilities.1'); 
      $entropy .= base64_decode($com->GetRandom(64, 0)); 
     } catch (Exception $ex) { 
     } 
    } 

    // try to read from the unix RNG 
    if (is_readable('/dev/urandom')) { 
     $h = fopen('/dev/urandom', 'rb'); 
     $entropy .= fread($h, 64); 
     fclose($h); 
    } 

    // create hash 
    $hash = hash('whirlpool', $entropy); 
    // truncate hash if max length imposed 
    if ($maxLength) { 
     return substr($hash, 0, $maxLength); 
    } 
    return $hash; 
} 

Answer 1

Le temps nécessaire pour créer le hachage n'est pas important, et tant que votre base de données est correctement indexée, la méthode de stockage ne doit pas non plus être un facteur important. Cependant, le hachage doit être transmis avec la demande du client à chaque fois, fréquemment sous forme de cookie. Les grands cookies peuvent ajouter une petite quantité de temps supplémentaire à chaque demande. Voir Yahoo!'s page performance best practices pour plus d'informations. Les petits biscuits, donc un hachage plus petit, ont des avantages. Dans l'ensemble, les grandes fonctions de hachage ne sont probablement pas justifiées. Pour leur portée limitée, les bons vieux md5 et sha1 sont probablement très bien comme source d'un jeton de session.

Answer 2

SHA1 ou MD5 est probablement suffisant pour vos besoins. En pratique, la probabilité d'une collision est si faible qu'elle ne se produira probablement jamais. En fin de compte, cependant, tout dépend de votre niveau de sécurité requis. Gardez également à l'esprit que les hachages plus longs sont à la fois plus coûteux à calculer et nécessitent plus d'espace de stockage.

Answer 3

L'article expire lorsque j'essaie de le lire, mais je ne peux pas trouver de raison d'utiliser un hachage comme identifiant de session. Les identifiants de session devraient être imprévisibles; vu le titre de l'article, il semble que les auteurs reconnaissent ce principe. Alors, pourquoi ne pas utiliser un générateur de nombres aléatoires cryptographiques pour produire des identifiants de session?

Un hachage prend une entrée, et si cette entrée est prévisible, il en est de même pour le hachage, et c'est mauvais.

Answer 4

Oui, la taille compte.

S'il est trop court, vous risquez des collisions. Il est également pratique pour un attaquant de trouver la session de quelqu'un d'autre par une attaque en force brute. Etre trop long compte moins, mais chaque octet de l'ID de session doit être transféré du navigateur au serveur à chaque requête, donc si vous optimisez vraiment les choses, vous ne voudrez peut-être pas un ID trop long. Cependant, vous n'avez pas besoin d'utiliser tous les bits d'un algorithme de hachage, rien ne vous empêche d'utiliser quelque chose comme Whirlpool, puis de ne prendre que les 128 premiers bits (32 caractères hexadécimaux).En pratique, 128 bits est également une bonne limite inférieure de longueur. Comme l'indique Erickson, l'utilisation d'un hachage est un peu étrange. À moins que vous n'ayez au moins autant d'entropie que la longueur de l'ID que vous utilisez, vous êtes vulnérable aux attaques qui devinent l'entrée de votre hachage.