Mon chiffrement d'authentification est-il bon?

Question

J'ai donc beaucoup lu sur le cryptage en PHP. Tellement que je ne suis pas sûr exactement ce qui est une très bonne méthode pour stocker en toute sécurité les informations de connexion.

Cependant, la fonction suivante est ce que je suis venu avec:

function loginHash($username, $password){ 
    $salt = str_split($password,(strlen($password)/2)+1); 
    $hash = hash('whirlpool', $username.$salt[0].'centerSalt'.$salt[1]); 
    return $hash; 
} 

Suis-je ce faire de la bonne façon? Il est utilisé pour authentifier un mot de passe combiné avec un nom d'utilisateur, et la capacité de comparer le hachage généré avec celui stocké dans une base de données pour vérifier une connexion.

Answer 1

Cryptage! = Hachage. Les deux sont généralement acceptés dans la catégorie de la cryptographie, mais quand quelque chose peut être crypté, il peut être déchiffré, ce qui n'est pas le cas dans Hashing. Hacher est juste un hachage, et c'est tout.

Le sel n'est en effet pas construit correctement. Il devrait être lu x-bytes de/dev/urandom avec un appel de fopen(). Par exemple, 16 octets de sel est ce que j'utilise personnellement. Cela empêche efficacement les attaques de la table arc-en-ciel.

Pour plus de sécurité, utilisez également une clé secrète. Par exemple:

$hashedPassword = hash_hmac('whirlpool',$password.$salt,$key); 

La clé $ est simplement une donnée aléatoire. Vous pouvez par exemple générer un fichier de 64 Ko appelé «key.bin» dans un dossier caché au-dessus de la racine du document et utiliser file_get_contents() avant le processus de hachage.

Pourquoi utiliser des clés secrètes? Si vous stockez les hachages et les sels dans une base de données et la clé dans le système de fichiers, alors cela empêche quiconque de craquer votre hachage s'ils mettent la main sur vos hachages et sels stockés. Ainsi, un attaquant devrait craquer dans la base de données et dans le système de fichiers pour déchiffrer vos hachages, mais remarquez qu'il est inutile de craquer vos hachages s'ils ont déjà craqué votre application, ce qui implique que votre système de hachage est bon.

Answer 2

Mon conseil est de ne jamais, jamais, jamais écrire vos propres fonctions de cryptage et de hachage. Même les experts se trompent tout le temps, alors ne l'essayez pas vous-même. J'ai entendu dire que phpass (Openwall) est un bon cadre de hachage, je vous suggère de l'utiliser.

Ils utilisent des sels dans leurs hachages et ont tout à fait quelques paramètres pour tordre le hachage.

Answer 3

Je pense que le code ci-dessus vérifie les deux cases.

• attaques de table Évite arc-en-(via sels)
• de connexion sécurisé

Answer 4

Vous n'êtes pas réellement un sel à l'aide.

Salt est une chaîne générée au hasard qui est incluse dans l'entrée pour votre fonction de hachage. En tant que tel, il sera différent à chaque fois. L'idée est que vous générez un salt lorsqu'un utilisateur stocke un mot de passe, et que ce sel est inclus dans votre stockage de données. Lors de l'authentification, vous récupérez le sel et le hachage stocké, vous préfixez le mot de passe donné avec le sel stocké et hachez les deux ensemble. Puis comparez le résultat avec le hachage stocké.

Answer 5

en utilisant le sel permet de résoudre deux problèmes:

1. tables arc-en-: tables arc-en-sont juste précalculées hash, stockés avec la valeur source. en comparant les hachages, vous obtenez la valeur non hachée (mot de passe). en ajoutant du sel, vous avez une autre couche de complexité - l'attaquant doit connaître le sel pour générer une table de hachage personnalisée.

2. différence de valeurs hachées: sans sel, les 2 mêmes mots de passe génèrent les mêmes 2 hachages. Maintenant, il est facile de voir si deux utilisateurs utilisent le même mot de passe (le point faible ici est à peu près le même que pour les tables arc-en-ciel, mais quand même). cela peut ne pas représenter beaucoup, mais c'est toujours un sujet de préoccupation.

En outre, vous ne devez pas utiliser d'algorithmes rapides pour le hachage de mot de passe. md5 est rapide, sha est rapide. le plus lent, le meilleur.

le blog matsano chargen est une bonne (et amusante) ressource pour les conseils et les pointeurs concernant la sécurité.