Comment stocker au mieux les informations utilisateur et le nom d'utilisateur et le mot de passe
J'utilise Mysql et je supposais qu'il valait mieux séparer les informations personnelles des utilisateurs et leur identifiant et mot de passe dans deux tableaux différents, puis les référencer simplement entre les deux.
Note: Pour clarifier mon message, je comprends les techniques de sécurisation du mot de passe (hachage, sel, etc.). Je sais simplement que si je suis des pratiques d'autres parties de ma vie (investissement, sauvegarde de données, voire stockage personnel), dans le pire des cas (comprenant une table ou un incendie), le fait de diviser les informations entre les tables offre le potentiel de protéger votre donnée supplémentaire.
Ne stockez pas de mots de passe. S'il se trouve sur un disque, il peut être volé. Au lieu de cela, stockez les hachages de mot de passe. tilisez l'algorithme de hachage droit , comme bcrypt (qui inclut un sel).
[~ # ~] modifier [~ # ~] : l'OP a répondu qu'il comprenait le problème ci-dessus.
Il n'est pas nécessaire de stocker le mot de passe dans une table physiquement différente de la connexion. Si une table de base de données est compromise, ce n'est pas un grand pas pour accéder à une autre table dans cette même base de données.
Si vous êtes suffisamment préoccupé par la sécurité et la sécurité en profondeur, vous pouvez envisager de stocker les informations d'identification de l'utilisateur dans un magasin de données complètement séparé de vos données de domaine. Une approche, généralement utilisée, consiste à stocker les informations d'identification dans un serveur d'annuaire LDAP. Cela peut également vous aider pour tout travail de connexion unique que vous effectuez plus tard.
Les mots de passe doivent être stockés sous forme de hachage cryptographique, qui est une opération non réversible qui empêche la lecture du texte brut. Lors de l'authentification des utilisateurs, la saisie du mot de passe est soumise au même processus de hachage et les hachages comparés.
Évitez l'utilisation d'un hachage rapide et bon marché tel que MD5 ou SHA1; l'objectif est de rendre coûteux pour un attaquant le calcul des tables Rainbow (basé sur les collisions de hachage); un hachage rapide contrecarre cela. L'utilisation d'un hachage coûteux n'est pas un problème pour les scénarios d'authentification, car il n'aura aucun effet sur une seule exécution du hachage.
En plus du hachage, salez le hachage avec une valeur générée aléatoirement; un nonce, qui est ensuite stocké dans la base de données et concaténé avec les données avant le hachage. Cela augmente le nombre de combinaisons possibles qui doivent être générées lors du calcul des collisions, et augmente ainsi la complexité temporelle globale de la génération de tables Rainbow.
La colonne de hachage de votre mot de passe peut être d'une longueur fixe; votre hachage cryptographique doit produire des valeurs qui peuvent être encodées en une longueur fixe, qui sera la même pour tous les hachages.
Dans la mesure du possible, évitez de lancer votre propre mécanisme d'authentification par mot de passe; utiliser une solution existante, telle que bcrypt.
Une excellente explication de la façon de gérer les mots de passe et de ce dont vous devez vous préoccuper est disponible sur http://www.matasano.com/log/958/enough-with-the-Rainbow-tables- ce que vous devez savoir sur les schémas de mots de passe sécurisés .
Enfin, n'oubliez pas que si un attaquant obtient l'accès à votre base de données, votre préoccupation immédiate devrait probablement concerner toute information sensible ou d'identification personnelle à laquelle il pourrait avoir accès et tout dommage qu'il aurait pu causer.
Il n'y a rien de mal à les mettre dans la même table. En fait, ce serait beaucoup plus rapide, donc je le recommande fortement. Je ne sais pas pourquoi tu voudrais le diviser.
Je vais essayer de répondre à votre question d'origine. Tout avoir dans une seule table est bien, sauf si vous avez juste beaucoup d'informations personnelles à collecter. Dans ce cas, il peut être judicieux de le diviser. Cette décision doit être prise en fonction de la quantité d'informations personnelles que vous traitez et de la fréquence à laquelle elles doivent être consultées.
Je dirais que la plupart du temps, je ferais quelque chose comme ça dans un seul tableau:
UserID, FirstName, LastName, Email, Password, TempPassword
Mais ... si vous recueillez bien plus que cela. Supposons que vous collectiez le téléphone, le fax, la date de naissance, la biographie, etc., etc. Et si la plupart de ces informations sont rarement consultées, je les mettrais probablement dans leur propre tableau et les relierais à une relation individuelle. Après tout, moins vous avez de colonnes sur une table, plus vos requêtes sur cette table seront rapides. Et parfois, il est logique de simplifier les tables les plus consultées. Il y a un impact sur les performances avec JOIN si vous avez besoin d'accéder à ces informations personnelles, c'est donc quelque chose que vous devrez considérer.
EDIT - Vous savez quoi, je viens de penser à quelque chose. Si vous créez un index sur le nom d'utilisateur ou le champ e-mail (selon votre préférence), cela éliminera presque complètement l'inconvénient des performances de créer autant de colonnes dans une table utilisateur. Je dis cela parce que chaque fois que vous vous connectez, la clause WHERE sera en fait extrêmement rapide pour trouver le nom d'utilisateur s'il a un index et cela n'aura pas d'importance si vous avez 100 colonnes dans cette table. J'ai donc changé d'avis. Je mettrais tout cela dans un seul tableau.;)
Dans les deux cas, comme la sécurité semble être un sujet populaire, le mot de passe doit être une valeur de hachage. Je suggère SHA1 (ou SHA256 si cela vous inquiète vraiment). TempPassword devrait également utiliser un hachage et il n'est là que pour la fonctionnalité de mot de passe oublié. De toute évidence, avec un hachage, vous ne pouvez pas décrypter et envoyer à l'utilisateur son mot de passe d'origine. Au lieu de cela, vous générez un mot de passe temporaire avec lequel ils peuvent se connecter, puis les forcez à changer de nouveau leur mot de passe après la connexion.
Est-ce que toutes ces données auront toujours une relation 1: 1 avec l'utilisateur? Si vous pouvez prévoir d'autoriser les utilisateurs à avoir plusieurs adresses, numéros de téléphone, etc., vous souhaiterez peut-être diviser les informations personnelles dans un tableau séparé.
Premièrement, pour énoncer (espérons-le) l'évidence, si vous pouvez en aucune façon éviter de stocker des noms d'utilisateur et des mots de passe, faites-le; c'est une grande responsabilité et si votre magasin d'informations d'identification est violé, il peut donner accès à de nombreux autres endroits pour les mêmes utilisateurs (en raison du partage de mot de passe).
Si vous devez stocker des informations d'identification:
- Ne stockez pas un formulaire réversible; stocker un hachage en utilisant un algorithme reconnu comme SHA-256. Utilisez un logiciel de chiffrement provenant d'une source fiable et fiable - N'ESSAYEZ PAS DE ROULER VOTRE PROPRE, VOUS VOUS OBTIENDREZ PROBABLEMENT.
- Pour chaque ensemble d'informations d'identification, stockez un sel avec les données hachées; ceci est utilisé pour "amorcer" le hachage de telle sorte que deux mots de passe identiques ne produisent pas le même hachage - car cela indique que les mots de passe sont les mêmes.
- Utilisez un générateur aléatoire sécurisé. Le faible caractère aléatoire est la première cause des échecs de sécurité liés au chiffrement, et non les algorithmes de chiffrement.
Si vous devez stocker réversible les informations d'identification:
- Choisissez un bon algorithme de chiffrement - AES-256, 3DES (daté) ou un chiffrement à clé publique. Utilisez un logiciel de chiffrement provenant d'une source fiable et fiable - N'ESSAYEZ PAS DE ROULER VOTRE PROPRE, VOUS VOUS OBTIENDREZ PROBABLEMENT.
- Pour chaque ensemble d'informations d'identification, stockez un sel (non chiffré) avec les données chiffrées; ceci est utilisé pour "amorcer" le chiffrement de chiffrement de telle sorte que deux mots de passe identiques ne produisent pas le même texte de chiffrement - car cela indique que les mots de passe sont les mêmes.
- Utilisez un générateur aléatoire sécurisé. Le faible caractère aléatoire est la première cause des échecs de sécurité liés au chiffrement, et non les algorithmes de chiffrement.
- Stockez la ou les clés de chiffrement/déchiffrement séparément de votre base de données, dans un fichier sécurisé O/S, accessible uniquement au profil d'exécution de vos applications. De cette façon, si votre base de données est violée (par exemple par injection SQL), votre clé n'est pas automatiquement vulnérable, car cela nécessiterait l'accès au disque dur en général. Si votre O/S prend en charge le cryptage de fichiers lié à un profil, utilisez-le - cela ne peut qu'aider et il est généralement transparent (par exemple, le cryptage NTFS).
- Si possible, stockez les clés elles-mêmes cryptées avec un mot de passe principal. Cela signifie généralement votre application. aura besoin de ce mot de passe au démarrage - il ne sert à rien de le fournir dans un paramètre à partir d'un script car si votre disque dur est violé, vous devez supposer que le fichier de clé et le script peuvent être affichés.
- Si le nom d'utilisateur n'est pas nécessaire pour localiser l'enregistrement de compte, cryptez à la fois le nom d'utilisateur et le mot de passe.
Dans mon expérience personnelle, le stockage des informations personnelles et des informations de connexion dans des bases de données individuelles est la meilleure pratique dans ce cas. La raison étant qu'une injection SQL doit avoir lieu, elle est limitée (à moins que l'infiltrateur ne connaisse la disposition interne de votre ou vos bases de données) à la table à laquelle les données se rapportent, par opposition à l'accès à l'ensemble du conglomérat de données.
Cependant, notez que cela peut se faire au détriment de la nécessité d'effectuer plus de requêtes, d'où un impact sur les performances.
Vous devez les stocker dans la même table et utiliser le cryptage unidirectionnel. MD5 fonctionnera, mais est faible, vous pouvez donc envisager quelque chose comme SHA1 ou une autre méthode. Il n'y a aucun avantage à stocker les 2 éléments dans des tableaux séparés.