est-il plus sûr de créer une table contenant des informations utilisateur et une autre pour leurs mots de passe que d'utiliser la même table pour tout?
8 Réponses :
Non, je ferais juste cela:
ID, nom d'utilisateur, mot de passe.
où l'ID est juste un autocrampe, le nom d'utilisateur est un varchar de 20 (environ, selon vos besoins) et le mot de passe est un mot de passe haché MD5 ou SHA1 avec un sel.
Utiliser deux tables pour cela n'a pas de sens. Ensuite, vous devez travailler avec des jointures pour obtenir les données. Et c'est juste un fardeau inutile.
N'oubliez pas d'ajouter le sel à la table aussi.
Vous n'avez pas nécessairement besoin de faire cela. Vous pouvez utiliser un sel pour chaque mot de passe. Si la base de données est piratée, elles n'ont pas le sel. Si vous l'ajoutez à la base de données, ils font. L'idée d'un sel est juste que l'utilisateur final n'a pas de contrôle final sur le hachage résultant.
Merci à tout le monde! Je suis au courant du hachage salé. Je me demandais simplement si vous avez deux tables ajoute une fonctionnalité de sécurité précieuse. À votre santé!
D'accord avec Michael - vous avez besoin de sels uniques par mot de passe. Vous devriez toujours supposer que le sel est disponible pour l'attaquant. Avec un sel global, l'attaquant peut construire un dictionnaire de mots de passe une fois et l'utiliser contre tous les utilisateurs de la base de données. Avec un sel unique-per-mots de passe, l'attaquant doit construire un dictionnaire différent pour chaque utilisateur , qui est difficile. S'il ne veut que le mot de passe pour un utilisateur spécifique, aucune autre approche ne va aider; Mais lorsque vous parlez de milliers d'utilisateurs, le sel unique aidera beaucoup.
Convenait avec le sel unique (par utilisateur), mais plutôt que de stocker le sel séparément à une nouvelle colonne, vous pouvez utiliser une colonne existante (avec des données statiques) comme sel - tel que le nom d'utilisateur.
Je suis d'accord avec l'idée d'un sel unique. Cela ressemble à une solution fine! À votre santé!
Il y a beaucoup trop de désinformation ici. Tout d'abord, n'utilisez plus MD5 ou SHA1. Il y a de meilleurs hashes disponibles, comme l'un des hachages SHA2. Deuxièmement, vous avez besoin d'un sel séparé pour chaque mot de passe que vous stockez et vous devez modifier le sel à chaque fois que vous modifiez le mot de passe. Un bon sel serait une valeur de 128 bits générée par un générateur de nombres pseudo-aléatoires cryptographiquement puissant (chaque langue en possède l'une d'entre elles). Vous pouvez stocker le sel et le mot de passe haché dans la même colonne si vous avez un bon schéma de sérialisation (voir Django's), mais il peut être plus facile de les stocker dans des colonnes séparées.
Troisièmement, il est judicieux d'utiliser une clé à l'échelle de l'application aussi , en plus d'un sel. Cette clé ne doit pas nécessairement être stockée dans la base de données. Cependant, la gestion des clés est difficile, ce n'est donc que si vous savez ce que vous faites. Quatrièmement, vous devez utiliser HMAC avec le sel ou la clé, si vous avez une clé. Cinquièmement, vous devriez exécuter plusieurs itérations (4096 ou 65536) du hachage.
@Justice, je ne vois pas le point dans plusieurs itérations d'un hachage salé? Sûrement si quelqu'un peut "craquer" votre algorithme de hachage (qui est en quelque sorte contre le concept de hashes), ils peuvent craquer n itérations de celui-ci ...
L'ensemble du point est de faire des ordres de grandeur plus longtemps pour un attaquant d'essayer de brut-forcer un ou tous les hayes dans des mots de passe, ou pour générer une table arc-en-ciel pour votre base de données. Lors de l'exécution de HMAC-SHA-256 est rapide, le fonctionnement 2 ^ 16 fois est beaucoup plus lent et un attaquant aura besoin de 2 ^ 16 fois plus de temps ou de puissance pour tenter de bruteforce de mots de passe ou générer des tables arc-en-ciel.
Mais une table arc-en-ciel contenant toutes les hayes SHA256 possibles contiendra certainement tous les hachages répétés .... C'est-à-dire: tout mot de passe aléatoire de 64 caractères de nombres, de lettres, de symboles, etc. est également susceptible d'être fissuré comme tout autre mot de passe aléatoire de 64 caractères de nombres , lettres, symboles
Non, ce n'est pas plus sûr. Assurez-vous simplement que vos mots de passe sont salés + hachés avant de les enregistrer dans la DB.
Non, je ne peux pas voir comment cela peut le rendre plus sûr.
Vous devriez réellement vous empêcher de stocker des mots de passe du tout. Stocker simplement leur hachage salé.
Lecture ultérieure:
+1 Absolument - il vous suffit de comparer les hachages égaux.
non. À moins que chaque table nécessitait un compte d'utilisateur différent pour y accéder - ce qui permettrait de l'interroger une douleur complète - et même à ce moment-là, le pirate informatique a élaboré un identifiant, il est donc probable qu'ils puissent obtenir l'autre.
Assurez-vous simplement que vous stockez des mots de passe sur une forme hachée, en utilisant un hachage sécurisé comme SHA-2 et un sel. Ne les stockez pas en texte brut et (IMHO) ne les stockez pas crypté.
Merci adam. J'étais dans cette longueur d'onde tout en réfléchissant à cela: le pirate hacker a-t-il accès à tout? Je suppose que cela m'a eu lieu tout en apprenant un peu unix et des fichiers tels que / etc / passwd et / etc / shadow. Après avoir lu les réponses à ma question, il est devenu évident que cette idée n'aide pas dans une application Web (sans oublier que l'affaire UNIX a une histoire).
Je suis en désaccord avec d'autres personnes - Placez les informations d'authentification dans une table séparée et dans la mesure du possible. Authentification pullière de votre application entièrement. Tu ne devrais pas m'enignir. Pensez que Siteminder etc. Votre application Web n'a aucune information sur la manière dont l'utilisateur est authentifié. Mot de passe, carte à puce, etc. (même chose avec Kerberos ou Active Directory sur les applications de bureau.)
Cette approche fonctionne même si vous utilisez un cadre comme la sécurité de printemps. Il suffit de configurer votre intercepteur afin qu'il regarde uniquement les tables d'authentification. Vous pouvez même utiliser des données de données séparées afin que votre intercepteur ne puisse pas voir les données de l'application ni vice versa.
Évidemment, votre demande aura toujours besoin de gérer des informations sur les autorisations de l'utilisateur, quelque chose généralement géré dans une table des «rôles». Mais il n'est pas nécessaire de savoir comment l'utilisateur a été authentifié.
Comment stockerait des noms d'utilisateur et des mots de passe dans un tableau séparé permettant de déterminer si l'application gère ou non l'authentification?
BTW, il y a déjà une bibliothèque de classe de hash salée (et puissante) assez simple (et puissant) (elles comprenaient également une petite démonstration de la manière d'utiliser la bibliothèque) là-bas - link .
Il fournit également un mécanisme de vérification (vous pouvez donc vérifier l'entrée de l'utilisateur sous forme de mot de passe valide) et choisir l'algorithme de hachage vous-même (SHA1 / MD5 / etc.)
Il n'y a pas d'avantage de sécurité, mais l'utilisation de plusieurs tables peut être utile pour stocker des informations d'identification à plusieurs systèmes liés à une seule connexion.
Comme mentionné ci-dessus, la sécurité doit être fournie par HASH salé pour des mots de passe.
Je pense avoir le nom d'utilisateur et le mot de passe de la même table, c'est d'accord,
mais j'ai également vu des gens qui font des choses stupides surtout lorsque vous travaillez avec l'ormes, quelqu'un pourrait finir par exposer les hachages de mot de passe, etc. P>
Par exemple, Framework C # P>
Quelqu'un peut simplement faire P>
appcontext.Users.ToList();