Je dirais que c'est un peu trop difficile compte tenu de ce que vous en retirez. Je pense que lorsque l'attaquant a accès à la base de données, vous avez des problèmes bien plus importants. Obfusquer le statut d'administrateur d'un utilisateur coûtera juste un peu plus de temps à l'attaquant, mais un APT (Advanced Persistent Threat) ne serait probablement pas découragé par ce fait.

La sécurité par obfuscation a au mieux une efficacité limitée - pour déterminer si elle est appropriée, vous devez comprendre les menaces que vous souhaitez contrer. Si un acteur de la menace peut lire directement votre base de données, quel avantage y a-t-il à masquer un détail stocké particulier?

S'il y a l'avantage de l'obscurcissement (assurez-vous que vous pouvez vraiment le prouver), alors utilisez le type d'obfuscation qui traite cette menace (valeurs chiffrées, sources de données hors ligne, hachage, etc.).

Je suis d'accord avec Black Magic que cela ne vaut probablement pas la peine, mais si vous le souhaitez, vous pouvez utiliser une fonction de dérivation de clé pour créer une clé de chiffrement basée sur le mot de passe, et l'utiliser pour chiffrer le contenu de la colonne Statut.

Le statut devrait potentiellement être conservé en mémoire pour toutes les sessions utilisateur ouvertes, afin que celles-ci soient toujours vulnérables à l'attaquant.

Cela signifierait que vous ont les mêmes restrictions que votre attaquant, en supposant que vous ne connaissez pas les mots de passe de vos utilisateurs. Vous ne pourriez pas lire le statut de la base de données, et si vous vouliez changer le statut d'un utilisateur, vous devrez changer son mot de passe en même temps.

De nombreux systèmes modernes séparent en fait la connexion de l'utilisateur (comment il s'authentifie) de ses «profils» (autorisations dont il dispose), implémentés sous la forme de deux ou plusieurs systèmes discrets. Votre serveur de connexion pourrait simplement avoir un GUID, un nom d'utilisateur haché et un mot de passe haché; en cas de connexion réussie, transférez la session sur le serveur d'applications. Tant que votre serveur d'applications n'est pas compromis, la base de données de connexion est inutile même si elle est vidée.

Comme étape supplémentaire, vous pouvez également crypter les données de l'utilisateur avec une clé du serveur de connexion (stockée dans le cadre de la session), ce qui rend également le serveur d'applications plus sécurisé. Deux systèmes sont généralement plus difficiles à vaincre qu'un. Cependant, si vous n'êtes pas prêt à configurer deux serveurs (ou clusters), et que tout cela semble être trop de travail, alors vous êtes probablement mieux avec votre conception actuelle de toute façon. Le simple fait de savoir quels comptes cibler ne facilite pas la tâche; si l'attaquant peut en casser un, il peut tous les casser avec le calcul parallèle.

La suggestion de PlasmaHH était de: "ajouter une lettre au mot de passe lorsqu'il est haché (en fait plusieurs lettres, c'était un" identifiant de groupe ") et demander au mécanisme d'authentification d'essayer toutes les combinaisons."

Bien que ce soit quelque peu la sécurité par l'obscurité, et doit être associé à de bonnes pratiques telles que:

• un facteur de travail important sur bcrypt
• les administrateurs ayant un mot de passe fort
• moyens d'empêcher l'attaquant d'avoir une copie de la base de données en premier lieu

C'est un bon moyen de ralentir suffisamment un attaquant pour que le mot de passe est changé avant d'être trouvé.

Cracker un mot de passe non trivial (en supposant que vous ayez utilisé un facteur de travail fort) peut prendre de quelques jours à quelques mois, donc c'est faisable, mais s'ils ne le font pas ' t savoir quel compte vaut la peine d'être piraté, cela les oblige à pirater chaque compte.

Donc, à moins qu'ils aient de la chance, ou que vous ayez nommé un compte administrateur "admin", ils devront essayer plusieurs comptes, ce sera faire leurs frais au moins une commande de mag nitude plus grande, ce qui oblige l'attaquant à attendre plus, à acheter plus d'énergie ou à abandonner.

En conclusion, ce n'est pas sans valeur, car c'est un moyen de dissuasion bon marché qui ne dérange pas l'utilisateur.

Notez que si vous avez des indices sur le fait que quelqu'un est administrateur, comme un message de quelqu'un d'autre modifié par lui (si seuls les administrateurs peuvent le faire), masquer son statut dans la base de données est inutile.

Comme d'autres l'ont mentionné, cela a des pièges comme vous empêcher de créer un utilisateur administrateur sans changer ou au moins demander son mot de passe.

Si disponible, demander une authentification à 2 facteurs pour les administrateurs serait probablement mieux moyen de sécuriser les comptes administrateur.

Oui, vous pouvez. Ajoutez simplement le statut d'administrateur dans le cadre du mot de passe.

comme: HereIsMe! 65371 = adminHereIsMe! 65370 = regular

Ensuite, lors de la connexion, essayez d'abord régulier puis admin, comme ceci:

  if (sha512 ($ password. "0") eq $ hash) {blabla user functions} else {if (sha512 ($ password. "1") eq $ hash) {blabla admin functions} else {show incorrect password message}}  

IMPORTANT: assurez-vous que quelqu'un ne peut pas modifier le dernier caractère de son propre mot de passe. Par exemple, assurez-vous que le formulaire d'inscription, le formulaire de mot de passe oublié et le formulaire de changement de mot de passe, ajoutez toujours un 0 ou un 1 à la fin du mot de passe en fonction de leur statut réel. cookie de session secondaire.

Cela rend pratiquement impossible de déduire l'état d'administrateur sans réussir à déchiffrer le mot de passe.

Si votre base de données le prend en charge, configurez un serveur d'authentification LDAP ou similaire, et les informations d'identification ne seront pas stockées localement.

Il y a plusieurs suggestions techniques intéressantes ici, mais il faut mentionner que même si vous les implémentez parfaitement, cette approche ne vous rapportera littéralement rien en cas d'intrusion pour les raisons suivantes:

• Si quelqu'un a accès à la base de données (par injection SQL ou quelque chose du genre), il est certain qu'il peut faire ce qu'il veut sur votre serveur avec les autorisations de n'importe quel utilisateur sous lequel votre service de base de données s'exécute depuis la plupart des systèmes de gestion de base de données fournissent des fonctionnalités pour manipuler des fichiers et exécuter des processus sur leur hôte. Cela signifie que l'intrus peut modifier vos pages Web ou le traitement côté serveur pour capturer des mots de passe en clair lors de la connexion et obtenir très rapidement des mots de passe non chiffrés pour vos utilisateurs actifs. Je suppose que votre compte administrateur est un utilisateur actif.
• Si quelqu'un accède à vos hachages de mot de passe, il ne va probablement pas sélectionner ceux qu'il doit essayer de déchiffrer en premier. Ils exécuteront simplement un cracker en masse pour les traiter tous en même temps et à chaque passage, il vérifiera tous les hachages de la table qu'ils traitent.
• Même si vous avez conservé le hachage de votre mot de passe administrateur une table séparée ou en dehors de la base de données entièrement, la compromission de comptes moins privilégiés entraînera probablement une élévation de privilèges tant que l'intrusion n'est pas détectée puisque l'intrus sera en mesure de se faire passer pour des utilisateurs de confiance pour accéder à plus d'informations (en utilisant un compte modérateur pour parler avec l'administrateur et lancer le vol de cookies ou toute autre activité malveillante, par exemple).
• Si votre site a des capacités sociales, il est très probable qu'il expose déjà d'autres moyens d'identifier les utilisateurs administratifs.

Si l'attaquant a accédé à la base de données, il peut simplement créer son propre hachage bcrypt et remplacer celui de la base de données. Il n'est pas nécessaire de déchiffrer le hachage.