Disons que je crée un microsite pour un client contenant des informations commerciales confidentielles. Nous devons le placer dans un emplacement auquel le client peut accéder, afin qu'il puisse approuver le lancement.
Si nous plaçons ce microsite derrière une connexion, nous avons une garantie que personne ne peut tomber sur le contenu et le compromettre. Mais que se passe-t-il si nous le publions dans un répertoire non divulgué et non indexé avec un nom de la même "force" que le mot de passe susmentionné? Pour des raisons d'argumentation, "non divulgué et non indexé" signifie qu'il ne sera pas manuellement ou automatiquement lié à / de n'importe où, ni indexé par une recherche de site Web sur le même domaine. Il ne sera pas non plus placé dans son propre sous-domaine, donc l'exploration DNS n'est pas un problème.
Mon instinct initial dit qu'il s'agit simplement de sécurité par obscurité, et est beaucoup moins sécurisé en raison du possibilité que quelqu'un trébuche dessus. Mais, après y avoir réfléchi, je ne suis pas si sûr. Voici ce que je comprends:
- Même en utilisant une chaîne de deux mots faible par dictionnaire pour le mot de passe et l'URL, il existe encore des milliards d'options devinables. Le placer dans l'URL ne réduit pas comme par magie cette liste.
- Les pages de connexion peuvent avoir une protection contre la force brute, de sorte qu'un attaquant obtiendrait de manière optimiste 20 tentatives de deviner. Les devinettes d'URL devraient être interceptées par la protection DoS ou anti-spam du serveur, et peuvent permettre à 200 estimations de produire 404 si vous prévoyez une attaque - toujours pas statistiquement significative pour des milliards d'options.
- La page de connexion est lié à partir d'un site Web - c'est un mur visible sur lequel un attaquant peut se battre. C'est la preuve que quelque chose vaut la peine d'être attaqué. Cependant, deviner l'URL est aveugle. Cela nécessite d'être sur le bon domaine (et sous-domaine), et de fonctionner avec la foi que, même après des dizaines de milliers de suppositions incorrectes, vous allez toujours changer quelque chose.
- L'URL a une susceptibilité supplémentaire d'être indexée / repérée en externe. Cependant, la plupart des araignées respectables ne «devinent» pas les sites, elles suivent simplement les liens. Une araignée malveillante "devinant" serait attrapée par la même protection DoS / spam que le point 2.
D'après ce que je peux dire, la seule différence significative entre les deux est la tranquillité d'esprit imaginée. La possibilité que l'URL puisse être trébuchée rend les gens nerveux et la connexion rend les choses sécurisées, même si elles semblent comparables sur la base des points ci-dessus. L'option d'URL s'oppose comme elle devrait être beaucoup moins sécurisée, cependant. Qu'est-ce que je ne prends pas en compte?
MODIFIER: Beaucoup de problèmes d'erreur humaine valides apparaissent. Cette question a été inspirée par un client qui implémente un degré de sécurité à l'épreuve des humains - connexion VPN via la télécommande, les gradateurs d'écran, les délais d'attente de 5 minutes, la panne des réseaux sociaux, etc. Pour cette question, veuillez supposer qu'aucun accès au réseau public et aucune violation accidentelle comme regarder l'épaule ou "oups! J'ai posté le lien vers Twitter!". Je recherche une réponse plus systématique, ou au moins une réponse plus satisfaisante que "les humains foutent la merde".
MODIFIER 2: Merci d'avoir signalé le doublon possible. IMHO, je pense que chacun a une valeur en tant que question individuelle. Cette question porte spécifiquement sur la sécurité des images et explore d'autres méthodes de sécurisation et de codage de ces données (par exemple, le codage en base64). Cette question aborde plus spécifiquement le concept de secret vs d'obscurité, et l'applique à la raison pour laquelle une connexion est meilleure qu'un URI indépendant du type de données en question. De plus, je ne pense pas que la réponse acceptée explique ma question particulière aussi profondément ou complètement que la bonne réponse de @ SteveDL ci-dessous.