2010-11-09 46 views
1

J'utilise salt pour crypter les mots de passe de mes utilisateurs. J'utilise PHP, et voici un exemple rapide de ce qui se passe pendant les registres d'utilisateurs.Authentifier une connexion utilisateur avec du sel

Ici, il est:

Code PHP:

// Gives me my random key. My salt generator. 
    $salt = uniqid(mt_rand()); 

    // My password via what users inputs. 
    $userpwd; 

    // Then the encryption. I use a HMAC hash. 
    $encrypted = hmac_hash("sha256", $userpwd, $salt); 
?> 

Maintenant que tous les travaux pour moi dans mon script. Mais ma question est, comment puis-je authentifier un utilisateur se connectant? Le nouveau mot de passe crypté est aléatoire, donc je ne peux pas comparer le mot de passe du formulaire de connexion au mot de passe crypté enregistré dans la base de données.

J'ai cherché et je ne trouve pas de solution. Peut-être que je n'ai pas cherché assez dur, mais est-il un moyen de déchiffrer le mot de passe? Que puis-je faire pour authentifier l'utilisateur avec mon script?

Répondre

3

Vous hachez le mot de passe saisi par l'utilisateur de la même manière, puis comparez le hachage à celui que vous avez enregistré.

if (hmac_hash("sha256", $_POST['password'], $saltFromDatabase) === $hashFromDatabase) 
    $login = true; 

Vous devez également stocker le sel car il est différent pour chaque utilisateur. Je recommande également d'utiliser un second salt constant dans l'application (stocké dans un fichier de configuration dur, de sorte que même si la base de données est compromise, les mots de passe sont toujours sécurisés).

Remarque: Le hachage est et non identique au chiffrement; C'est un processus irréversible.

+0

Merci, c'est ce que je ferai alors. Je stocke mon sel dans un fichier de configuration. J'ai lu beaucoup de gens disant stocker le sel dans le db mais je ne me sentais pas à l'aise avec ça.Juste au cas où le db était compromis. – Mario

+1

Mais gardez à l'esprit que l'utilisation du même sel pour tout le monde réduit le temps de calcul requis pour un attaquant en force brute. –

+0

Il conduira également au même hachage si plus d'une personne a le même mot de passe. Il est préférable d'avoir un sel par utilisateur (par mot de passe). – Aether

0

Vous ne décryptez pas ce que vous avez stocké. Vous hachez le mot de passe entré et comparez-le avec ce qui a été stocké lors de l'inscription. En effet, si deux hachages correspondent (à toutes fins utiles), vous pouvez être sûr que les données source correspondent.

-2

Votre sel doit être constant et non aléatoire. De cette façon, lorsque vous vérifiez le mot de passe par rapport au hachage, tout ce que vous avez à faire est de hacher l'entrée avec le sel à nouveau, et le hachage qui en résulte doit être le même que ce qui est sorti auparavant.

+0

Ok. Donc, ne pas avoir un sel généré au hasard? Utilisez un sel constant? J'ai lu beaucoup de gens qui sauvent la corde de sel dans le db. Est-ce une bonne pratique? – Mario

+1

Un sel, par définition, n'est * pas * une constante, mais une valeur aléatoire. http://stackoverflow.com/questions/1645161/salt-generation-and-open-source-software/1645190#1645190 – Jacco

+0

@Jacco constante à l'élément d'information avec lequel le mot de passe s'identifie. Donc, dans ce cas, peut-être certaines données spécifiques à l'utilisateur. Unique, pas aléatoire. –

8

Vous devez générer un sel unique pour le mot de passe de chaque utilisateur, puis stocker la valeur du sel quelque part, vous pouvez le récupérer. Par exemple, en enregistrant le sel dans une table user avec le nom d'utilisateur et le mot de passe haché. De cette façon, vous pouvez extraire le sel connu et l'exécuter via votre fonction lorsque vous allez authentifier un utilisateur.

Voici un article qui contient plus d'informations: Storing Passwords - done right!

Et pour plus d'informations sur les sels: salt-generation-and-open-source-software

+0

Je ne sais pas pourquoi cela serait downvoted ... –

+0

Un sel doit aléatoire. (Si ce n'est pas aléatoire, nous l'appelons une clé) http://stackoverflow.com/questions/1645161/salt-generation-and-open-source-software/1645190#1645190 – Jacco

+3

Absolument. De ce post: "Utiliser un nouveau sel chaque fois que vous créez un nouveau mot de passe ou changez un mot de passe". Je suis d'accord que vous devez calculer un nouveau sel unique chaque fois qu'un mot de passe est généré. Ensuite, vous pouvez stocker ce sel dans la base de données, comme je l'ai suggéré. Je vois comment ma réponse n'a pas vraiment expliqué cela clairement, donc je l'ai révisé ... –

0

Vous chiffrez le mot de passe utilisé pour se connecter et de le comparer avec le mot de passe crypté dans votre base de données. :)

0

Vous calculez le hash du mot de passe que l'utilisateur a saisi, comme vous le faites lors de son enregistrement. Notez que le code est semi-pseudo, vous devez l'adapter à vos bibliothèques ou fonctions.

$res = db('SELECT etc FROM users WHERE user=? AND pass=?', 
    $_POST['user'], hmac_hash("sha256", $_POST['pass'], $salt)); 
if(numRows($res) > 0) { 
    // continue with authentication 
} 

Si le sel est stocké dans la db, alors vous devez soit le chercher d'abord, ou faire la comparaison dans la db.

+1

vous devriez chercher le sel de la db en premier lieu au lieu d'envoyer le mot de passe non-haché à la base de données. – Jacco