L'obscurcissement / obscurcissement des identifiants de bases de données accessibles au public est-il vraiment une «meilleure pratique»?

J'ai entendu des gens parler ici et là sur Internet qu'il est préférable de masquer les identifiants de base de données publics dans les applications Web. Je suppose qu'ils signifient principalement dans les formes et dans les URL, mais je n'ai jamais rien lu de plus qu'une bouchée sur le sujet.

EDIT : Bien sûr, maintenant que je pose cette question, je trouve quelques ressources sur le sujet:

• /programming/2374538/obscuring-database-ids
• /programming/1895685/should-i-obscure-primary-key-values
• http://joshua.schachter.org/2007/01/autoincrement.html

Ces liens ont satisfait ma curiosité, mais les messages SO n'ont pas beaucoup de votes et ne sont pas nécessairement centrés sur le sujet dans ce contexte, donc je ne sais pas quoi en penser, et certains d'entre eux affirment que le troisième le lien est faux. Je laisserai le reste de mon message intact:

Je comprends les différences entre l'obscurité et la sécurité, ainsi que la façon dont les deux peuvent fonctionner ensemble, mais je ne peux pas imaginer pourquoi cela serait nécessaire.

Y a-t-il une vérité à cela, est-ce juste de la paranoïa, ou est-ce simplement totalement faux?

Je peux penser à des façons de le faire, mais bien sûr, cela ajoute beaucoup de complexité au code de l'application. Dans quelles circonstances cela serait-il utile? Si c'est quelque chose que les gens font fréquemment, comment est-il généralement déployé? Hachage des identifiants? Autre chose? Cela semble beaucoup de travail pour pas beaucoup de sécurité supplémentaire. Je ne cherche pas de vraies solutions, je veux juste avoir une idée de comment / pourquoi les gens feraient cela dans le monde réel.

Est-ce vraiment considéré comme une "meilleure pratique" ou s'agit-il simplement d'une micro-optimisation de peu de valeur?

REMARQUE : je pense que quelques personnes ont peut-être eu une mauvaise idée: je ne suggère pas que les identifiants difficiles à deviner soient le seul mécanisme de sécurité, il y aurait évidemment les contrôles d'accès habituels. Supposons que ceux-ci sont en place et que le simple fait de connaître l'ID ou l'ID haché d'un enregistrement ne suffit pas pour accorder l'accès.

Je ne pense pas que ce soit si important, mais il y a certains scénarios où cela pourrait avoir de l' importance en fonction des autres décisions que vous prenez.

Par exemple, si vous deviez exposer un ID de commande généré de manière séquentielle, et que vous aviez une attaque d'ingénierie sociale avec quelqu'un appelant le support client et disant "hé, je viens de dépenser 2000 $ sur un nouvel ordinateur et vous m'avez envoyé la commande d'un autre gars pour un câble de 15 $, maintenant je suis à 2 000 $ "vous pourriez passer beaucoup de temps à essayer de vérifier le problème avant de conclure qu'il est faux ou d'envoyer au faux un nouvel ordinateur.

Il existe des variations similaires, moins sophistiquées, mais embarrassantes sur le thème; si un méchant incrémente un ID de commande, un lien envoyé par e-mail vers un reçu, et si aucune validation supplémentaire n'est effectuée pour vérifier que la personne qui a cliqué sur le lien a le droit d'afficher l'ID de commande, soudainement, vous exposez involontairement des informations privées sur les clients à la mauvaise personne.

Dans de tels cas, si les nombres ne sont pas séquentiels, l'exposition est légèrement atténuée car les suppositions sont moins susceptibles de donner des résultats intéressants. D'un autre côté, vous avez maintenant besoin d'un moyen pratique de référencer un ID de commande dans les interactions de support client qui n'entraînera pas de longues conversations aller-retour avec les interactions client par téléphone tandis que votre représentant essaie de faire la distinction entre B, PD et T dans le numéro de commande BPT2015D.

Je dirais qu'il est exagéré d'appeler cet obscurcissement une "meilleure pratique", mais dans certains scénarios, cela peut réduire la facilité d'exploitation d'une autre faiblesse de votre code de validation ou d'autorisation. D'un autre côté, peu importe que quelqu'un sache que vous avez écrit le billet de blog # 1 ou # 2559. Si l'ID n'est pas une information précieuse, même avec des connaissances supplémentaires, l'argument selon lequel l'obscurcir est une meilleure pratique a moins de poids.

Il existe un deuxième argument potentiel, à savoir que votre identifiant de base de données peut vous marier à une implémentation (ou une instance) de base de données particulière, et lorsque votre entreprise est rachetée ou prend un concurrent et que vous devez maintenant fusionner deux systèmes hérités, ou le PDG sort boire avec le représentant de DynoCoreBase et ils décident que vous allez maintenant déplacer toutes vos données vers DynoCoreBase version 13h et il veut que toutes les clés primaires soient des guids, et vous devez créer une sorte de couche de mappage pour traduire les anciens ID en nouveaux ID afin que les anciennes URL ne se cassent pas, mais que ces scénarios vous importent dépendent beaucoup plus de la nature de votre entreprise (et de l'implication du client avec ces ID) que de toute meilleure pratique générale.

Voici ma façon de voir les choses:

Bien que la «sécurité par l'obscurité» ne soit évidemment pas suffisante, l'obscurité peut contribuer à la sécurité, même si elle est un peu. Vous devez décider si ce petit peu de sécurité de sécurité vaut l'effort supplémentaire qu'il faut pour déployer quelque chose comme ça dans votre application.

Il y a une autre raison en dehors de la sécurité à laquelle je peux penser pour implémenter ceci:

Intimité

Disons que nous avons affaire à des identifiants utilisateur dans l'URL. Si l'ID utilisateur de Joe est 100et l'ID utilisateur de Bob est 101, il est probablement évident que le compte de Joe a été créé en premier. Bien que cela puisse ne pas avoir d'importance dans la plupart des applications, cela peut être important pour certains. Ceci est un exemple de confidentialité strictement par l'obscurité, donc à moins que vous n'ayez un système très sophistiqué d'obscurcissement des identifiants utilisateur, il pourrait être assez facile de dissoudre et de déterminer si l'utilisateur avec id 3Js9kW3hTs7sa120a un compte plus long que l'utilisateur avec id Q8Hs73kks0hEg.

Du lien que j'ai référencé:

Le premier est que, étant donné l'URL d'un objet, vous pouvez déterminer les URL des objets qui ont été créés autour de lui. Cela expose le nombre d'objets dans votre base de données à d'éventuels concurrents ou à d'autres personnes que vous ne souhaitez peut-être pas avoir ces informations (comme l' ont démontré les Alliés en devinant les niveaux de production des chars allemands en regardant les numéros de série).

L'utilisation d'un identifiant d'incrémentation automatique expose publiquement le nombre d'objets dans la base de données et peut exposer ceux qui ont été créés en premier et ceux qui sont plus récents. Cette information peut révéler le fait qu'une entreprise est nouvelle ou ne se porte pas bien même. Par exemple: disons que vous commandez un livre et que votre identifiant de commande est 1. Il peut être évident que votre commande était la première du système, ce qui peut être déconcertant. Disons que vous revenez en commander un autre et que votre identifiant de commande est 9. Cela indique que seules 7 commandes ont été passées dans le délai entre vos deux commandes. Ces informations pourraient être précieuses pour les concurrents. Dans ce cas, l'ID d'incrémentation numérique numérique est probablement mieux obscurci.

Le mot «obscur» est probablement un peu trompeur ici, et peut amener les gens à penser «obscurcir» ou «cacher partiellement».

Il est recommandé de ne jamais inclure de clés de base de données générées en interne dans le cadre d'une URL publique si ces enregistrements de base de données contiennent des données sensibles.

C'est tout simplement trop facile de jouer avec les chiffres de l'URL et d'accéder à d'autres enregistrements.

Je vais aller à l'encontre du courant dominant et vous dire que l'utilisation d'un identifiant aléatoire long est à mon avis une forme de sécurité assez décente.

Il doit être clair pour quiconque a accès à ces données qu'elles sont aussi sensibles qu'un mot de passe. Et bien sûr, il a l'inconvénient que s'il se met à l'état sauvage, il peut être plus difficile à changer.

Mais il présente quelques avantages par rapport à la paire username / mot de passe habituelle. Tout d'abord, l'utilisateur n'a pas le choix, vous pouvez donc être sûr qu'il est essentiellement impossible à deviner. Il est inutile de concevoir un site parfaitement sécurisé lorsque l'administrateur choisit son prénom comme mot de passe. Deuxièmement, chaque élément a un identifiant différent, donc si l'un accède à un élément, cela n'aide pas l'autre.

Bien sûr, plus il y a de couches de sécurité, mieux c'est. Mais cette méthode à elle seule peut être plus sûre que quelques informations d'identification.

Il y a deux aspects à cela: la convivialité et la sécurité.

Pour la sécurité, masquer les identifiants est plutôt inutile; ce qui est important, c'est que l'ID ne doit jamais être la seule «clé» d'une ressource non publique. Cela signifie que si vous souhaitez donner aux utilisateurs sélectionnés l'accès à une certaine page, il ne suffit pas d'exiger l'ID de la page dans l'URL, vous devez implémenter un mécanisme de sécurité réel tel qu'une connexion par nom d'utilisateur / mot de passe ou authentification par clé publique / privée, ainsi qu'une autorisation appropriée (c'est-à-dire que le système doit pouvoir juger au cas par cas si l'utilisateur X est autorisé à accéder à la ressource Y et agir en conséquence).

Du point de vue de l'utilisabilité, le conseil général est de garder les clés artificielles cachées: elles n'ont aucun sens pour l'utilisateur, et en les révélant de manière évidente, vous introduisez une dépendance supplémentaire, qui est particulièrement difficile à gérer car elle vit à l'extérieur le domaine du logiciel - les gens noteront, enverront par e-mail, fax, impression, signet, etc., ces identifiants, et si vous les changez, vous aurez des tickets de support ennuyeux.

Non , vous ne voulez absolument pas autoriser l'accès à des ressources arbitraires simplement en connaissant leur identifiant interne. Ceci est Internet, quelle que soit la présence d' enfant malicieux, criminel, ou simplement vous pouvez l' imaginer Exister, existe réellement , et tôt ou tard ils vont venir à votre site. À moins que tout ce que vous pourriez servir soit complètement public pour tout le monde (et si vous n'avez qu'un seul client, c'est garanti que ce n'est pas le cas), vous devez restreindre l'accès à ceux qui sont réellement autorisés à en avoir.

La solution habituelle consiste à utiliser des jetons d'autorisation d'une sorte qui sont stockés dans une session cryptée et vérifie que quelque chose est censé être visible pour l'utilisateur authentifié avant de l'envoyer. Il peut s'agir d'un véritable gestionnaire de sécurité, tel que celui fourni avec le JDK, ou de tout autre composant remplissant le même rôle, à condition qu'il le fasse de manière cohérente. (La question de savoir si exposer les identifiants internes à une personne déjà authentifiée est également une question intéressante avec divers avantages et inconvénients, mais elle est moins essentielle à la sécurité.)

La valeur de faire cela est difficile à calculer jusqu'à ce que vous soyez réellement attaqué par quelqu'un qui veut dire affaires. Ensuite, c'est généralement la différence entre cesser ses activités et se contenter de hausser les épaules encore un autre kiddie déjoué.

Évidemment, cela dépend de la sensibilité des données, mais pour une sécurité moyenne, le minimum que je ferais serait d'inclure l'ID et une valeur de somme de contrôle.

Générez la somme de contrôle en ajoutant du sel (c'est-à-dire un ensemble de caractères aléatoires) avant et après l'ID et en effectuant un MD5 sur la valeur.

Sur chaque page qui lit la valeur ID, elle doit générer la valeur de somme de contrôle et la comparer avec celle transmise, refuser la demande si elle ne correspond pas.

Si un pirate potentiel est en mesure d'obtenir suffisamment de combinaisons valides, il pourra peut-être déterminer la valeur de Salt par force brute, donc si vous pouvez ajouter une autre couche de sécurité telle que la vérification de l'ID utilisateur qui vous aidera également.