Chiffrement/Hachage de texte en clair les mots de passe en base de données

J'ai hérité une application web que je viens de découvrir les magasins de plus de 300 000 noms d'utilisateur/mots de passe en clair dans une base de données SQL Server. Je me rends compte que c'est une Très Mauvaise Chose™.

Sachant que je vais mettre à jour le login et le mot de passe de processus de mise à jour pour crypter/décrypter, et avec le plus petit impact sur le reste du système, que recommanderiez-vous comme le meilleur moyen de supprimer le texte en clair les mots de passe de la base de données?

Toute aide est appréciée.

Edit: Désolé si je n'était pas clair, je voulais vous demander quel serait votre procédure pour crypter/hachage du mot de passe, pas de chiffrement/méthodes de hachage.

Dois-je simplement:

  1. Faire un backup de la DB
  2. Mise à jour de l'ouverture/mise à jour le mot de passe de code
  3. Après les heures de travail, aller à travers tous les enregistrements dans la table de hachage du mot de passe et le remplacement de chacun
  4. De Test pour s'assurer que les utilisateurs peuvent toujours login/mise à jour des mots de passe

Je suppose que mon problème est plus du nombre d'utilisateurs, donc je veux m'assurer que je suis en train de faire cela correctement.

  • Très Mauvaise Chose(tm) 🙂
  • Je ne pense pas que vous avez travaillé à vos question. Vous voulez savoir comment obtenir les données d'une base de données relationnelle? Que serait une instruction select.
  • Je sais comment récupérer des documents, c'est plus une question de procédure... Désolé si c'était pas clair.
  • Avez-vous mis la main sur le Reddit utilisateur DB? 😉
  • Double Possible de Sécuriser le Hachage de Mot de passe
  • Je ne suis pas sûr de savoir comment cet enfant de 7 ans question avec plus de 34 000 points de vue est un doublon de 6 ans question avec moins de 5 000 points de vue, mais apparemment, vous pensez qu'elle est. Je suis d'accord que je ne voudrais pas demander à ce qu'une nouvelle question sur DONC, aujourd'hui, mais cela a été demandé avant toutes les autres émissions liées à la Pile de sites d'Échange de l'existence. La question elle-même est plus sur le processus de migration à partir de texte brut, plus sûrs, les mots de passe, pas de la mise en œuvre spécifique de chiffrement/méthodes de hachage.
  • Tout simplement parce que nous avons laissé les doublons de rester pour quelques années ne signifie pas que nous devrions les garder ouverts quand nous les trouvons. Et je ne vois pas comment l'existence d'autres sites SE sont pertinentes.
  • Aussi, puisque vous êtes toujours là, je suggère de commutation de la accepté de répondre à un bon one — pas celle qui prétend que les mots de passe sont “crypté”, ou que MD5 est un bon choix pour un hachage de mot de passe. stackoverflow.com/a/287883 et stackoverflow.com/a/287738 sont les meilleures réponses qu'ils ont laissé sur un hash du mot de passe doit être salé et lent.
  • Ma mention d'autres SE sites était de répéter que c'était plus d'un processus/procédure de question que j'aurais sans doute demandé sur programmers.stackexchange.com s'il avait existé quand j'ai demandé à l'origine. Je ne pense pas que ce soit un doublon que je n'ai pas demandé algorithme de hachage doit être utilisé. L'actuel accepté réponse a été la meilleure réponse à l'époque que la question d'un processus de migration de texte clair des mots de passe pour plus de sécurité mise en œuvre.

InformationsquelleAutor Jonathan S. | 2008-11-13
  1. 19

    J'imagine que vous devez ajouter une colonne à la base de données pour le mot de passe crypté, puis exécutez un lot de travail au-dessus de tous les enregistrements qui obtient le mot de passe actuel, le chiffre (comme d'autres l'ont mentiond un hachage comme md5 est assez standard edit: mais ne doit pas être utilisé sur son propre - voir les autres réponses pour de bonnes discussions), le stocke dans la nouvelle colonne et vérifie tout cela s'est fait en douceur.

    Ensuite, vous devrez mettre à jour votre front-end de hachage de passe saisi par l'utilisateur au moment de la connexion et vérifiez que vs le hash stocké, plutôt que de vérifier en clair-vs-texte en clair.

    Il semblerait prudent de me laisser les deux colonnes de la place pour un peu de temps pour s'assurer que rien n'hinky, a connu, avant de finalement retirer les mots de passe en clair tous ensemble.

    Ne pas oublier aussi qu'à chaque fois que le mot de passe s'effectue le code de changement, tels que le changement de mot de passe /rappel des demandes. Vous aurez bien sûr de perdre la capacité de email mot de passe oublié, mais ce n'est pas une mauvaise chose. Vous aurez à utiliser un mot de passe de réinitialisation du système à la place.

    Edit:
    Un dernier point, vous pouvez envisager d'éviter l'erreur que j'ai faite lors de ma première tentative à un banc d'essai de connexion sécurisée du site web:

    Lors du traitement du mot de passe utilisateur, envisager où la de hachage prend place. Dans mon cas, le hash est calculé par le code PHP en cours d'exécution sur le serveur, mais le mot de passe a été transmis à la page à partir de la machine de l'utilisateur en clair! C'était ok(ish) dans l'environnement, j'ai travaillé en, car elle était à l'intérieur d'un https système de toute façon (uni en réseau). Mais, dans le monde réel, j'imagine que vous voulez de hachage du mot de passe avant qu'il ne quitte le système de l'utilisateur, à l'aide de javascript etc. et puis de transmettre le hash de votre site.

    • Merci, bien que je n'aime pas garder les mots de passe autour d'eux, ils ont déjà été autour depuis des années... Le système envoie plusieurs mails, qui comprennent des mots de passe donc je vais devoir regarder l'avant de décider sur l'utilisation d'un algorithme de hachage.
    • Ce qui se passe si ils ont le javascript désactivé?
    • Vous ne pouvez pas hacher le mot de passe sur l'ordinateur de l'utilisateur. Le malaxage doit être fait par un système de confiance. (Sinon, toute personne qui a volé une copie du mot de passe de la table peut juste vous envoyer la valeur de hachage; le hachage est devenu le mot de passe.) Mais, oui, cela va nécessiter un transport sécurisé comme HTTPS de l'utilisateur.
    • Qui se transforme rapidement en un historique de préoccupation. Très, très peu de gens désactiver le js. Dans ce cas, cependant, je voudrais envoyer le unhashed passer pour le serveur et de les adapter pour que dans le code côté serveur. Il serait tout simplement une moins-idéal de secours.
    • pour ceux qui sont particulièrement paranoïaque, vous pouvez stocker le col double hachée dans la DB et accepter une seule hachée passer par le client.
    • Soit de hachage ou de ne pas hachage. Le hachage sur le client est inutile. Le modèle de menace que vous vous adressez à une table de hachage est l'exposition du mot de passe de la base de données. Si ce n'est pas un souci, ne pas hachage à tous. Sinon, vous ne peut pas s'authentifier à l'aide d'un algorithme de hachage produit par l'utilisateur (ou de lire à partir d'un vol de copie de base de données).
    • Il peut être uber-paranoïaque, je viens de le mentionner quelque chose que je n'ai pas d'adresse à la fois. Comme je l'ai dit, je n'ai pas du monde réel, actif experiance de meilleures pratiques dans ce domaine, mais il est somethingworth considérant.

    InformationsquelleAutor xan
  2. 49

    MODIFIER (2016): utilisation Argon2, scrypt, bcrypt, ou PBKDF2, dans cet ordre de préférence. Utiliser un facteur de ralentissement que possible pour votre situation. Utiliser une approuvés de mise en œuvre existantes. Assurez-vous d'utiliser un bon sel (bien que les bibliothèques que vous utilisez doit être bien sûre de le faire pour vous).

    Lorsque vous hachage de mots de passe à utiliser NE PAS UTILISER de PLAINE MD5.

    Utilisation PBKDF2, ce qui signifie fondamentalement à l'aide d'un hasard de sel pour éviter table arc-en-ciel attaques, et d'itération (re-hachage) assez de temps pour ralentir le hachage baisse pas tant que votre application prend trop de temps, mais assez qu'un attaquant brute-forcer un grand nombre de mot de passe différent remarquerez

    À partir du document:

    • Itérer au moins 1000 fois, de préférence plus de temps de votre application pour voir combien d'itérations sont réalisables pour vous.
    • 8 octets (64 bits) de sel sont suffisantes, et l'aléatoire n'a pas besoin d'être sécurisé (le sel est clair, nous ne sommes pas inquiets pour quelqu'un va le deviner).
    • Un bon moyen pour appliquer le sel lors de hachage est d'utiliser l'algorithme HMAC-vous avec votre favori algorithme de hachage, en utilisant le mot de passe de la clé HMAC et le sel, comme le texte de hachage (voir cette section du document).

    Exemple d'implémentation en Python, en utilisant SHA-256 secure hash:

    MODIFIER: comme mentionné par Eli Collins ce n'est pas un PBKDF2 mise en œuvre. Vous devriez préférer les implémentations qui collent à la norme, comme la PassLib.

    from hashlib import sha256
from hmac import HMAC
import random

def random_bytes(num_bytes):
  return "".join(chr(random.randrange(256)) for i in xrange(num_bytes))

def pbkdf_sha256(password, salt, iterations):
  result = password
  for i in xrange(iterations):
    result = HMAC(result, salt, sha256).digest() # use HMAC to apply the salt
  return result

NUM_ITERATIONS = 5000
def hash_password(plain_password):
  salt = random_bytes(8) # 64 bits

  hashed_password = pbkdf_sha256(plain_password, salt, NUM_ITERATIONS)

  # return the salt and hashed password, encoded in base64 and split with ","
  return salt.encode("base64").strip() + "," + hashed_password.encode("base64").strip()

def check_password(saved_password_entry, plain_password):
  salt, hashed_password = saved_password_entry.split(",")
  salt = salt.decode("base64")
  hashed_password = hashed_password.decode("base64")

  return hashed_password == pbkdf_sha256(plain_password, salt, NUM_ITERATIONS)

password_entry = hash_password("mysecret")
print password_entry # will print, for example: 8Y1ZO8Y1pi4=,r7Acg5iRiZ/x4QwFLhPMjASESxesoIcdJRSDkqWYfaA=
check_password(password_entry, "mysecret") # returns True
    • J'ai toujours compris que le hachage hachage n'est pas quelque chose que vous devriez faire, comme la possibilité de hash collision augmentent à chaque itération. Mais est-ce de hachage(sel+hash) de contourner cela? Le nombre de personnages ne sont pas tout ce que beaucoup, après tout...
    • Vous avez raison, re-hachage peut réduire l'espace de recherche (le sel n'aide pas), mais cela est sans importance pour le mot de passe de base de la cryptographie. Pour atteindre les 256 bits de l'espace de recherche de ce hash vous auriez besoin d'un complètement aléatoire de mot de passe, 40 caractères, disponible à partir de tous les caractères du clavier (log2(94^40)).
    • Les gens doivent être conscients que ce code n'est PAS de mettre en œuvre l'algorithme PBKDF2; mais plutôt une non-standard de la variation de l'ancienne PBKDF1 fonction, modifié pour utiliser un PRF (HMAC-SHA256 dans ce cas). Voir rfc2898 pour l'implémentation de référence de deux kdfs. Bien que cet algorithme n'est probablement pas de l'insécurité, ce n'est pas des octets soit compatible avec la PBKDF1 ou PBKDF2, ni du comportement exact la même analyse de la sécurité - je suis préoccupé par le fait qu'elle s'applique l'algorithme HMAC fixe de sel, et varys le mot de passe au lieu - ce qui peut affaiblir HMAC.
    • Pas complètement en désaccord, depuis PBKDF2 crée des clés de longueur arbitraire et ce code ne fonctionne pas. Cela n'a pas de sens, bien sûr, un mot de passe-régime de la sécurité sociale. Mais le <a href="texte" >tools.ietf.org/html/rfc2898#appendix-B.1.1">texte dans la rfc-vous liés à</a> mentionne explicitement en utilisant le mot de passe que HMAC "clé" et le sel, comme HMAC du "texte", ce qui est - l'intention - ce que cet exemple de code fait.
    • La cryptographie n'est pas quelque chose où assez proche est généralement une bonne idée, surtout si les gens prennent cela pour un PBKDF2 mise en œuvre, seulement pour découvrir plus tard que la sortie ne correspond pas à un code existant/données. C'est vrai, si le code est le sel/mot de passe défauts ont été corrigés, il serait plus conforme à l'annexe, mais c'est seulement décrivant l'utilisation de HMAC dans PBKDF2; pas comment PBKDf2 œuvres. Outre l'omission de la variable keylen partie, la question la plus importante est que le code ci-dessus omet complètement le XOR partie de la fonction F() dans PBKDF2 - qui est au centre de la preimage résistance.
    • Juste pour ajouter - pour la plupart algorithme de discussions, certaines implémentations peuvent varier, en tant qu'ils obtenir l'effet désiré. Mais PBKDf2 est soigneusement conçu algorithme, avec vecteurs de test en spécifiant le comportement exact; et c'est dans un espace-problème où de légères modifications peut signifier une diminution grave de la sécurité. Dans la plupart des autres cas, je n'aurais pas pensé tout de même la peine de mentionner 🙂
    • Je suis d'accord.

    InformationsquelleAutor orip
  3. 38

    La stratégie de base consiste à utiliser une fonction de dérivation de clé de "hachage" le mot de passe avec un peu de sel. Le sel et le résultat du hachage sont stockées dans la base de données. Lorsqu'un utilisateur entre un mot de passe, le sel et leurs commentaires sont hachés et de la même façon par rapport à la valeur stockée. Si elles correspondent, l'utilisateur est authentifié.

    Le diable est dans les détails. D'abord, cela dépend beaucoup de l'algorithme de hachage qui est choisi. Une dérivation de clé algorithme de type PBKDF2, basé sur une base de hachage code d'authentification de message, la rend "mathématiquement impossible" de trouver une entrée (dans ce cas, un mot de passe) qui va produire une donnée de sortie (ce qu'un attaquant a trouvé dans la base de données).

    Un pré-calculées d'attaque par dictionnaire utilise de pré-calculées de l'indice, ou de dictionnaire, à partir de hachage sorties pour les mots de passe. Le hachage est lent (ou il est censé être, de toute façon), donc l'attaquant de hachages toutes les chances de mots de passe une fois, et stocke le résultat indexés de manière telle que la donnée d'une table de hachage, il peut chercher un mot de passe correspondant. C'est un classique compromis à trouver de l'espace pour le temps. Depuis listes de mots de passe peut être énorme, il ya des façons de régler le compromis (comme rainbow tables), de sorte qu'un attaquant peut donner un peu de vitesse pour gagner beaucoup d'espace.

    Pré-calcul attentats sont déjoués par l'aide de "chiffrement de sel". C'est quelques données qui est haché avec le mot de passe. Il n'a pas besoin d'être un secret, il a juste besoin d'être imprévisible pour un mot de passe donné. Pour chaque valeur de sel, un attaquant aurait besoin d'un nouveau dictionnaire. Si vous utilisez un octet de sel, un attaquant doit 256 exemplaires de leur dictionnaire, chaque produit avec un autre sel. D'abord, il faudrait utiliser le sel pour la recherche de la bonne dictionnaire, alors qu'il avait utiliser le hachage de sortie pour rechercher un mot de passe utilisable. Mais que faire si vous ajoutez 4 octets? Maintenant il a besoin de 4 milliards de copies de la le dictionnaire. En utilisant un assez gros sel, une attaque par dictionnaire est interdit. Dans la pratique, de 8 à 16 octets de données à partir d'un chiffrement de qualité générateur de nombre aléatoire qui fait un bon sel.

    Avec pré-calcul de la table, un attaquant a besoin de calculer la valeur de hachage sur chaque tentative. Combien de temps il faut pour trouver un mot de passe dépend désormais entièrement sur combien de temps il faut pour hacher un candidat. Ce temps est augmenté par l'itération de la fonction de hachage. Le nombre d'itérations est généralement un paramètre de la fonction de dérivation de clé; aujourd'hui, un grand nombre d'appareils mobiles utilisent de 10 000 à 20 000 itérations, alors qu'un serveur peut utiliser 100 000 habitants ou plus. (Le bcrypt algorithme utilise le terme "facteur de coût", qui est une mesure logarithmique du temps requis.)

    • Autant que de hachage génération censé être lent - qui repose sur l'utilisation de la table de hachage. Pour le stockage de mot de passe, c'est une qualité souhaitable. Pour l'authentification des messages, il peut ne pas l'être (en particulier si les messages en cours d'authentification, sont des paquets de réseau).
    • Bon point; la lenteur est important pour protéger contre une attaque hors connexion. Dans un protocole réseau, un homme-dans-le-milieu ne serait probablement pas eu le temps de trouver une collision avec un très rapide de hachage, tant qu'il n'était pas cassé.
    • Un libellé explication de cryptage de mot de passe et les conditions, merci.
    • +1 pour bcrypt...
    InformationsquelleAutor erickson
  4. 4

    Suivre Xan conseils de garder le mot de passe actuel autour de la colonne pour un certain temps donc, si les choses tournent mal, vous pouvez la restauration rapide-n-facile.

    Aussi loin que le chiffrement de vos mots de passe:

    • utiliser un sel
    • utiliser un algorithme de hachage pour les mots de passe (c'est à dire., - c'est lent)

    Voir Thomas Ptacek de Assez Avec Les Tables Arc-En-Ciel: Ce Que Vous Devez Savoir Sur Les Régimes De Mot De Passe Sécurisé pour certains détails.

    InformationsquelleAutor Michael Burr
  5. 3

    Je pense que vous devriez faire ce qui suit:

    1. Créer une nouvelle colonne intitulée HASHED_PASSWORD ou quelque chose de similaire.
    2. Modifier votre code pour qu'il vérifie pour les deux colonnes.
    3. Progressivement migrer les mots de passe à partir de la non-haché table à la hachées une. Par exemple, lorsqu'un utilisateur se connecte, migrer son mot de passe automatiquement à la hachée supprimer la colonne et l'unhashed version. Tous les nouveaux utilisateurs enregistrés pourront avoir des mots de passe hachés.
    4. Après les heures d'ouverture, vous pouvez exécuter un script qui permet de migrer les n utilisateurs un temps
    5. Lorsque vous n'avez plus unhashed les mots de passe de gauche, vous pouvez supprimer votre ancien mot de passe dans la colonne (vous ne pouvez pas être en mesure de le faire, dépend de la base de données que vous utilisez). Aussi, vous pouvez supprimer le code pour gérer les anciens mots de passe.
    6. Vous avez terminé!
    InformationsquelleAutor Tamas Czinege
  6. 3

    C'était un problème de mine il ya quelques semaines.
    Nous avons été le déploiement d'un grand projet MIS à 975 différents lieux géographiques où nos propres informations d'identification des utilisateurs magasin sera utilisé comme un authentificateur de jeu différent de déjà mises en œuvre et à l'utilisation des applications. Nous avons déjà fourni à la fois le REPOS et du SAVON à base d'authentification de service, mais le client a insisté pour être en mesure d'atteindre l'utilisateur banque d'informations d'identification à partir d'autres applications avec juste une connexion DB à vue en lecture seule de la table ou de la vue. Soupir... (ce très couplé mauvaise décision de conception est un objet d'une autre question).

    Qui nous a forcé de s'asseoir et de convertir nos salé et de manière itérative hachage de mot de passe de stockage de régime à un cahier des charges et de fournir des différentes implémentations de langue pour une intégration facile.

    Nous l'avons appelé Assez Sécurisé des mots de passe Hachés ou FSHP en bref.
    Mis en œuvre en Python, Ruby, PHP5 et l'a publié dans le Domaine Public. Disponible à être consommés, fourche, flammé ou de cracher sur GitHub à http://github.com/bdd/fshp

    FSHP est un salée, de manière itérative hachage hachage de mot de passe de mise en œuvre.

    Principe de conception est similaire avec PBKDF1 de la spécification RFC 2898
    (un.k.un: PKCS #5: Mot de passe-Cryptographie Basé sur la Spécification de la Version 2.0.)
    FSHP permet de choisir le sel de la longueur, le nombre d'itérations et le
    sous-jacent fonction de hachage cryptographique parmi SHA-1 et SHA-2 (256, 384, 512).
    Auto-définition de méta préfixe au début de chaque sortie le rend portable tout en permettant au consommateur de choisir son propre mot de passe de stockage de sécurité de base.

    De SÉCURITÉ:

    Par défaut FSHP1 utilise 8 octets sels, avec 4096 itérations de hachage SHA-256.
    - 8 octets sel rend la rainbow table des attaques peu pratique en multipliant les
    espace requis avec 2^64.
    - 4096 itérations causes des attaques de force brute être assez cher.
    - Il n'y a pas d'attaques connues contre SHA-256 pour trouver les collisions avec
    un effort de calcul de moins de 2^128 opérations au moment de l'
    cette version.

    IMPLÉMENTATIONS:

    • Python: Testé avec 2.3.5 (w/hashlib), 2.5.1, 2.6.1
    • Ruby : Testé avec 1.8.6
    • PHP5 : Testé avec 5.2.6

    Tout le monde est le bienvenu pour créer manquant implémentations de langue ou de
    polonais actuel.

    FONCTIONNEMENT de BASE (avec Python):

    >>> fsh = fshp.crypt('OrpheanBeholderScryDoubt')
>>> print fsh
{FSHP1|8|4096}GVSUFDAjdh0vBosn1GUhzGLHP7BmkbCZVH/3TQqGIjADXpc+6NCg3g==
>>> fshp.validate('OrpheanBeholderScryDoubt', fsh)
True

    PERSONNALISATION DE LA CRYPTE:

    Nous allons affaiblir notre hachage de mot de passe système.
    - Diminuer le sel de la longueur par défaut de 8 à 2.
    - Diminution de l'itération tour de défaut 4096 à 10.
    - Sélectionnez FSHP0 avec l'algorithme SHA-1 de sous-jacent à l'algorithme de hachage.

    >>> fsh = fshp.crypt('ExecuteOrder66', saltlen=2, rounds=10, variant=0)
>>> print fsh
{FSHP0|2|10}Nge7yRT/vueEGVFPIxcDjiaHQGFQaQ==
    • C'est assez cool! Il serait agréable de ne pas préciser la variante comme un nombre magique mais.
    • en fait c'est plus qu'un algo de la carte. à l'heure de cette publication, toutes les variantes sont PBKDF1 implémentations et ne diffèrent que par algo de hachage (0:SHA1, 1:SHA256, 2:SHA384 3:SHA512) mais pour être compatible, je l'ai pris comme un entier. il n'est donc pas un nombre magique, mais le même goût. vous avez raison.
    • Je veux garder FSHP comme une option viable et mettre à jour que le temps des mandats de vue de la sécurité. Peut-être que des variantes 4, 5 & 6 sera PBKDF2 avec SHA256,384,512 algorithmes. C'est un exemple bien sûr. 🙂
    InformationsquelleAutor Berk D. Demir
  7. 2

    Comme d'autres l'ont mentionné, vous ne voulez pas à déchiffrer si vous pouvez l'aider. Norme de meilleure pratique consiste à chiffrer à l'aide d'un hachage à sens unique, et puis quand l'utilisateur ouvre une session dans le hachage de mot de passe pour la comparer.

    Sinon, vous devrez utiliser un chiffrement fort pour crypter et décrypter. Je ne pourrais que recommander cet si les raisons politiques sont fortes (par exemple, vos utilisateurs sont habitués à être en mesure d'appeler le service d'assistance pour récupérer son mot de passe, et vous avez une forte pression à partir du haut de ne pas changer cela). Dans ce cas, j'aimerais commencer avec le chiffrement et puis commencer à construire un business case pour déplacer de hachage.

    InformationsquelleAutor Cory Foy
  8. 2

    À des fins d'authentification, vous devriez éviter de stocker les mots de passe en utilisant un chiffrement réversible, c'est à dire vous ne devez stocker le hachage de mot de passe et vérifier le hash de l'utilisateur-mot de passe fourni avec le hachage que vous avez stockées. Cependant, cette approche a un inconvénient: il est vulnérable à la table arc-en-ciel attaques, si un attaquant d'obtenir votre mot de passe de base de données de banque.

    Ce que vous devez faire est de stocker les valeurs de hachage de pré-choisi (et secret) de sel de la valeur + le mot de passe. I. e., concaténer le sel et le mot de passe, le résultat de hachage, et de stocker ces hachage. Lors de l'authentification, procédez de la même concaténer votre sel de la valeur et de l'utilisateur-mot de passe fourni, de hachage, puis vérifier l'égalité. Cela rend arc-en-ciel de la table des attaques irréalisable.

    Bien sûr, si l'utilisateur d'envoyer des mots de passe sur le réseau (par exemple, si vous travaillez sur un site web ou une application client-serveur), alors vous ne devriez pas envoyer le mot de passe en texte clair à travers, de sorte qu'au lieu de stocker de hachage(sel + mot de passe), vous devez stocker et vérifier à l'encontre de hachage(sel + hash(mot de passe)), et demandez à votre client de pré-hachage de l'utilisateur-mot de passe fourni et envoyer que un à travers le réseau. Cela protège l'utilisateur de votre mot de passe ainsi, si l'utilisateur (comme beaucoup le font) ré-utiliser le même mot de passe pour plusieurs fins.

    • Le sel n'a pas besoin d'être secret, et c'est lourd à garder son secret.
    • Aussi, pour être claire, le sel doit être différentes et au hasard pour chaque instance. Pas de pré-choisi une fois, et pour toutes les tables de hachage.
    • Mike est bien sûr le droit, en principe, cependant, il n'est pas toujours possible de changer de sel à chaque fois (en fonction de l'application spécificités), cas dans lequel le sel doit être gardé secret.
    InformationsquelleAutor Mihai Limbășan
  9. 1
    • Chiffrer en utilisant quelque chose comme MD5, encoder comme une chaîne hexadécimale de
    • Vous avez besoin d'un sel; dans votre cas, le nom d'utilisateur peut être utilisé comme le sel (il doit être unique, le nom d'utilisateur doit être le plus unique de la valeur disponible 😉
    • utiliser le champ ancien mot de passe pour stocker le MD5, mais la balise MD5 (j'.e.g "MD5:687A878....") pour que le vieux (texte brut) et la nouvelle (MD5) les mots de passe peuvent co-exister
    • changement de la procédure de connexion pour vérifier contre le MD5 si il y a un MD5, et contre le mot de passe en clair sinon
    • modifier "modifier mot de passe" et "nouvel utilisateur" des fonctions pour créer MD5 ed les mots de passe uniquement
    • maintenant, vous pouvez exécuter la conversion par lots de travail, qui peut prendre aussi longtemps que nécessaire
    • après la conversion a été exécuté, supprimer l'héritage de soutien
    • Il est également fréquent d'utiliser un hasard de sel pour chaque utilisateur et de les stocker à côté le mot de passe haché.
    • Quelque chose qui est inconnu à l'utilisateur de rendre plus sûr le sel. Peut-être un interne userID ou, Michael l'a suggéré, un spécialement créé sel de la valeur. Si vous utilisez la disposition du public, unique en sel, comme nom d'utilisateur, vous devriez sans doute aussi du sel avec une constante, pour faire bonne mesure.
    • Si je comprends bien, le salage a pour but de prévenir les attaques par dictionnaire (pré-calculer les hachages de populaire les mots de passe et en comparant les utilisateurs à eux). Le sel est toujours visible, il n'est pas un secret. Alors pourquoi ne pas utiliser le nom d'utilisateur, puisqu'il est déjà connu, et la garantie d'être unique?
    • Nom d'utilisateur n'est pas une mauvaise sel, si vous envisagez un seul système. Mais il serait sans doute utile pour l'attaquant comme un gouvernement répressif pour faire de dictionnaires pour la plupart des noms d'utilisateur pour augmenter leurs chances de s'implanter sur de multiples sites. Il est préférable de choisir et de stocker un hasard de sel.
    • -1 pour le jeûne hachage md5.
    InformationsquelleAutor mfx
  10. 1

    Étape 1: Ajouter chiffré champ de base de données

    Étape 2: Modifier le code de sorte que lorsque le mot de passe est changé, il met à jour les champs, mais la journalisation en utilise encore l'ancien champ.

    Étape 3: Exécution de script pour remplir tous les champs.

    Étape 4: Modifier le code de sorte que la coupe de bois dans les utilisations nouvelles de champ et de modification des mots de passe s'arrête la mise à jour de l'ancien champs.

    Étape 5: Supprimer les mots de passe non cryptés dans la base de données.

    Cela devrait vous permettre d'accomplir le passage sans interruption pour l'utilisateur final.

    Aussi:
    Quelque chose que je ferais est le nom de la nouvelle base de données de champ de quelque chose qui est complètement sans rapport avec le mot de passe comme "LastSessionID" ou quelque chose de même ennuyeux. Alors au lieu de supprimer le mot de passe champ, il suffit de remplir avec des tables de hachage de données aléatoires. Ensuite, si votre base de données n'est jamais compromise, ils peuvent passer tout le temps qu'ils veulent essayer de déchiffrer le champ "password".

    Cela peut ne pas accomplir quoi que ce soit, mais c'est amusant de penser à quelqu'un assis là, à essayer de comprendre sans valeur d'information

    • Bon point sur l'Étape 2 sont nécessaires dès le début du processus. Je partage votre plaisir de la tétine champ de mot de passe trop 🙂
    InformationsquelleAutor Kevin
  11. 0

    Comme avec toutes les décisions de sécurité, il y a des différences. Si vous hachage du mot de passe, ce qui est probablement votre plus facile de se déplacer, vous ne pouvez pas offrir une récupération de mot de passe la fonction qui renvoie le mot de passe d'origine, ni de votre personnel de l'oeil d'une personne à un mot de passe afin d'accéder à leur compte.

    Vous pouvez utiliser le chiffrement symétrique, qui a ses propres inconvénients. (Si votre serveur est compromis, la clé de chiffrement symétrique peut être compromise aussi).

    Vous pouvez utiliser de chiffrement à clé publique, et d'exécuter récupération de mot de passe/service client sur une autre machine qui stocke la clé privée en isolement à partir de l'application web. C'est le plus sûr, mais nécessite un deux-architecture de la machine, et probablement un pare-feu entre les deux.

    • L'incapacité du personnel à rechercher un utilisateur par mot de passe) est une fonction, pas un inconvénient. Support de récupération de mot de passe n'est pas un compromis, c'est une capitulation.
    • Je pense que c'est une malheureusement position absolutiste pour prendre sur cette. Cela dépend vraiment de la valeur de la sécurité de l'information protégée par mot de passe.
    • Il dépend aussi de plus sur la taille et la fiabilité du personnel en question. Mot de passe recherche fait beaucoup plus de sens dans une organisation de petite taille que dans un grand.
    • Vous ne savez jamais ce que un mot de passe protège; de permettre aux utilisateurs de réutiliser les mots de passe pour leur banque sur votre jouet de l'application web. Même si votre personnel est digne de confiance (même si c'est juste), VOUS ne pouvez pas exclure la possibilité d'un attaquant externe arriver à votre mot de passe de la base de données.
    • Si le personnel a un intérêt légitime à accéder à un autre compte utilisateur, cette fonction doit être intégré dans le système sans le personnel besoin de se connecter en tant qu'utilisateur. Et la perception de la nécessité d'une "récupération de mot de passe du système" peut être remplacé par une " réinitialisation du mot de passe système.
    InformationsquelleAutor davidcl
  12. 0

    Je ne suis pas un expert en sécurité, mais je htink la recommandation actuelle est d'utiliser bcrypt/blowfish ou SHA-2 variante, pas de MD5 /SHA1.

    Probablement vous avez besoin de penser en termes d'un plein d'audit de sécurité, trop

    InformationsquelleAutor Gene T
  13. 0

    MD5 et SHA1 ont montré un peu de faiblesse (en deux mots peuvent entraîner dans le même hash) donc, en utilisant SHA256-SHA512 /itératif hachages est recommandé de hacher le mot de passe.

    Je voudrais écrire un petit programme dans la langue que l'application est écrite dans ce va et génère de façon aléatoire un sel qui est unique pour chaque utilisateur et un hachage du mot de passe. La raison j'ai tendance à utiliser le même langage que la vérification est que les différentes bibliothèques de chiffrement peut faire les choses de façon légèrement différente (c'est à dire de remplissage) donc, en utilisant la même bibliothèque pour générer le hachage et de vérifier qu'il élimine ce risque. Cette application peut aussi puis vérifier la connexion après le tableau a été mis à jour si vous voulez qu'il connaît la plaine de texte mot de passe encore.

    1. Ne pas utiliser MD5/SHA1
    2. Générer une bonne aléatoire de sel (de nombreuses bibliothèques de chiffrement ont un générateur de sel)
    3. Un processus itératif de l'algorithme de hachage comme orip recommandé
    4. De s'assurer que les mots de passe ne sont pas transmis en clair sur le fil
    InformationsquelleAutor Kudos2u2
  14. 0

    Je voudrais suggérer une amélioration à le grand exemple python posté par Orip. Je voudrais redéfinir le random_bytes de la fonction:

    def random_bytes(num_bytes):
    return os.urandom(num_bytes)

    Bien sûr, vous devez importer le os module. Le os.urandom fonction fournit une séquence aléatoire d'octets qui peut être utilisé en toute sécurité dans les applications cryptographiques. Voir la référence de l'aide de cette fonction pour plus de détails.

    InformationsquelleAutor Sergio
  15. -1

    De hachage du mot de passe, vous pouvez utiliser le HashBytes fonction. Retourne un varbinary, de sorte que vous devez créer une nouvelle colonne, puis supprimez l'ancien varchar un.

    Comme

    ALTER TABLE users ADD COLUMN hashedPassword varbinary(max);
ALTER TABLE users ADD COLUMN salt char(10);
--Generate random salts and update the column, after that
UPDATE users SET hashedPassword = HashBytes('SHA1',salt + '|' + password);

    Ensuite, vous modifiez le code pour valider le mot de passe, à l'aide d'une requête comme

    SELECT count(*) from users WHERE hashedPassword = 
HashBytes('SHA1',salt + '|' + <password>)

    où <mot de passe> est la valeur entrée par l'utilisateur.

    InformationsquelleAutor Vinko Vrsalovic
  16. -5

    de hachage avec md5. c'est ce qui est généralement fait avec des mots de passe.

    InformationsquelleAutor Mladen Prajdic