Puis-je masquer quel compte dans ma base de données est le compte administrateur, donc un attaquant ne saura pas quel hachage à cracker en premier?
Disons que j'avais une base de données qui ressemblait à ceci:
Name Password hash (bcrypt) Status
--------------------------------------------------------------------------------
Dave $2y$10SyyWTpNB.TyWd3nM hQ41frOtObcircAb3nJw1Cf9dC6CT7tVIEb6XS Standard
Sarah $2y$10$fUJrNA200sXgWUJAP7XEiuq4itHa43Y8QVIpc/YWscgVJ PYWbLLV. Admin
Mike $2y$10$01jx7u7hnfKOzBYyjNWskOPQ23w1Cf1gNiv42wsKqXKOf8filzS02 Standard
Si un attaquant obtenait l'accès à cette base de données, il verrait immédiatement que Sarah est une administratrice et se concentrerait probablement sur la suppression de ce mot de passe, afin d'avoir plus de pouvoir. Existe-t-il un moyen de cacher d'une manière ou d'une autre si quelqu'un est un administrateur dans la base de données afin qu'un attaquant ne sache pas qui sont les administrateurs? Je pourrais simplement hacher la valeur (standard ou admin) mais cela ne donnerait qu'un bit d'entropie, et j'espère obtenir un peu plus de sécurité que cela.
Je dirais que c'est un peu trop difficile de considérer 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. Obscurcir le statut d'administrateur d'un utilisateur coûtera juste un peu plus de temps à l'attaquant, mais une APT (menace persistante avancée) ne serait probablement pas dissuadée par ce fait.
La sécurité par obscurcissement 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 à cacher un détail stocké particulier?
S'il y a est avantage dans l'obfuscation (assurez-vous que vous pouvez vraiment le prouver), alors utilisez le type d'obfuscation qui répond à 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 cryptage basée sur le mot de passe, et l'utiliser pour crypter le contenu du statut colonne.
Potentiellement, le statut devrait être conservé en mémoire pour toutes les sessions utilisateur ouvertes, de sorte que celles-ci pourraient toujours être vulnérables à l'attaquant.
Cela signifierait que vous auriez 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 l'état de la base de données, et si vous vouliez changer un état d'utilisateur, vous devriez changer leur mot de passe en même temps.
De nombreux systèmes modernes séparent en fait les informations de connexion de l'utilisateur (comment ils s'authentifient) de leurs "profils" (autorisations dont ils disposent), implémentés comme deux ou plusieurs systèmes discrets. Votre serveur de connexion peut 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 trop de travail, 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 lors du hachage (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 un peu la sécurité par l'obscurité, et doit être associé à de bonnes pratiques comme:
- un fort facteur de travail sur bcrypt
- administrateurs ayant un mot de passe fort
- façons 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 soit modifié avant d'être trouvé.
Cracker un mot de passe non trivial (en supposant que vous avez utilisé un facteur de travail fort) peut prendre de quelques jours à quelques mois, donc c'est faisable, mais s'ils ne savent pas quel compte mérite d'être piraté, cela les oblige à pirater chaque compte .
Donc, à moins qu'ils n'aient de la chance ou que vous ayez nommé un compte administrateur "admin", ils devront essayer plusieurs comptes, ce qui augmentera leurs coûts d'au moins un ordre de grandeur, ce qui fera que l'attaquant attendra plus, achètera plus de puissance ou donnera vers le haut.
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 que quelqu'un est un administrateur, comme un article de quelqu'un d'autre édité par eux (si seuls les administrateurs peuvent le faire), masquer leur statut dans la base de données est inutile.
Comme d'autres l'ont mentionné, cela a du mal à vous empêcher de créer un administrateur utilisateur sans changer ou au moins demander son mot de passe.
Si elle est disponible, demander une authentification à 2 facteurs pour les administrateurs serait probablement un meilleur moyen de sécuriser les comptes d'administrateur.
Oui, vous pouvez. Ajoutez simplement le statut d'administrateur dans le cadre du mot de passe.
comme: HereIsMe! 65371 = admin HereIsMe! 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 1 à la fin du mot de passe en fonction de leur statut réel. Stockez l'état dans une session côté serveur, de préférence chiffrée à l'aide d'un cookie de session côté client.
Cela rend pratiquement impossible de déduire le statut d'administrateur sans avoir réussi à déchiffrer le mot de passe.
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 (bien que l'injection SQL ou quelque chose comme ça), il est certain qu'ils peuvent à peu près faire ce qu'ils veulent sur votre serveur avec les autorisations de l'utilisateur sous lequel votre service de base de données s'exécute, car 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 les 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 se connecter sur ceux qu'il devrait essayer de résoudre en premier. Ils exécuteront simplement un cracker en vrac pour les traiter tous à la fois et à chaque passage, il vérifiera tous les hachages de la table qu'ils traitent.
- Même si vous avez conservé votre hachage de mot de passe administrateur dans une table distincte ou à l'extérieur de la base de données, le compromis de comptes moins privilégiés entraînera probablement une escalade de privilèges tant que l'intrusion n'est pas détectée, car l'intrus sera en mesure d'usurper l'identité d'utilisateurs de confiance pour accéder à plus d'informations (en utilisant un compte de modérateur pour parler avec l'administrateur et lancer le vol de cookies ou toute autre activité malveillante, par exemple).
- Si votre site possède des capacités sociales, il est très probable qu'il expose déjà d'autres façons d'identifier les utilisateurs administratifs.
Si votre base de données la prend en charge, configurez un serveur d'authentification LDAP ou similaire, puis les informations d'identification ne seront pas stockées localement.