2009-10-18 4 views
0

mon algorithme ressemble à ceci:changer de md5 à SHA1, le salage

$new_password = sha1($salt . $password . $email); 

cela fonctionne bien, mais Im essayant de changer de SHA1 depuis ive entendu son mieux, mais il ne fonctionnera pas. Pourquoi donc?

registre:

//generate a strong unique salt 
$salt = uniqid(mt_rand()); 

$new_password = sha1($salt . $password . $email); 

puis je ressasser quand je me connecte

+0

Ce qui ne fonctionne pas? Y at-il des messages d'erreur – Yacoby

+2

S'il vous plaît ne pas rouler votre propre code de hachage de mot de passe et lire cette réponse: http://stackoverflow.com/questions/1581610/help-me-make-my-password-storage-safe/1581919#1581919 – Inshallah

+0

Avez-vous déjà des valeurs de hachage MD5 dans votre base de données? Ou voulez-vous juste utiliser 'sha1' au lieu de' md5' dès le début? – Gumbo

Répondre

3

Entreposez-vous le sel avec le mot de passe haché? Vous devez utiliser le même sel lors de la vérification du hachage - chaque utilisateur doit avoir son adresse e-mail, le sel et le hachage stockés.

+0

Greg a raison. Vous devrez soit stocker le sel dans un champ db séparé ou inclure le sel dans le hachage avec un délimiteur comme ceci: $ hash = $ salt. '$'. sha1 ($ salt. $ mot de passe. $ email); – Mark

-1

Vous voulez une chaîne constante pour votre sel, par exemple

$salt = "iodized sea salt" 

EDIT: Les commentateurs et downvoters ici semblent ne pas comprendre le concept d'un sel. En utilisant un sel constant ne serait certainement pas vaincre le but du sel, qui est de faire votre choix de l'algorithme de hachage ("SHA1 avec tel ou tel un sel") privé. Ce sel peut être long et son choix a plus d'entropie que, disons, uniqid (mt_rand()). Vous ne pouvez pas forcer un long sel à n'importe quel moment de ce côté de jamais. Un sel par utilisateur peut vous aider à vous sentir mieux si vous n'êtes pas sûr de la sécurité informatique, mais ne procure aucun autre avantage.

+3

Vous réalisez que cela supprime tout le point d'un sel? – Yacoby

+0

Pas complètement - c'est toujours mieux que pas de sel. Cela signifie simplement qu'un attaquant devrait générer sa propre table arc-en-ciel plutôt que d'en utiliser une existante. – Greg

+2

Ce n'est pas mieux que de ne pas utiliser de sel du tout. L'utilisation d'un sel constant permettra à un adversaire de faire une recherche de force brute contre l'ensemble des hachages de mots de passe acquis en une seule fois, au lieu d'un seul. – Inshallah

0

Oui, sha1 est un meilleur hachage que md5. La plupart du temps, tho, md5 est assez bon ... Vraiment, comment "insécurité" votre site est déterminé beaucoup plus par d'autres facteurs.

+1

Je suppose que cela dépend un peu de la détermination d'un adversaire à vous briser la sécurité. Trouver des collisions MD5 est pratique avec une certaine quantité de puissance de calcul, et la puissance de calcul n'est pas si difficile à trouver. – Inshallah

+1

simplement parce qu'une autre partie n'est pas sûre n'est pas une excuse pour utiliser un algorithme qui est cryptographiquement cassé et impropre à une utilisation ultérieure. – Jacco

+0

Je parlais d'utilisations de MD5 qui ne sont pas principalement liées à la sécurité ... Bien sûr, utilisez sha1 pour vos hachages de mots de passe ... Mais il y a beaucoup d'utilisations pour les hachages (par exemple, détection de modification de fichier). Je n'essaie pas de faire valoir que quelqu'un devrait utiliser un hachage non sécurisé, juste que je parie que son site sécurisant l'énergie serait mieux utilisé pour la validation de formulaire ou la protection contre xss que la différence de sécurité entre sha1 et md5 ... – dicroce