Les URL privées et non devinables sont-elles équivalentes à l'authentification par mot de passe?
Je souhaite exposer une ressource sur le Web. Je veux protéger cette ressource: m'assurer qu'elle n'est accessible qu'à certaines personnes.
Je pourrais mettre en place une sorte de authentification par mot de passe. Par exemple, je pouvais uniquement autoriser l'accès à la ressource via un serveur Web qui vérifie les demandes entrantes pour les informations d'identification correctes (peut-être par rapport à une base de données de sauvegarde d'utilisateurs) avant de servir le fichier.
Alternativement, je pourrais simplement utiliser un RL privée. Autrement dit, je pourrais simplement héberger la ressource sur un chemin impossible à deviner, par exemple https://example.com/23idcojj20ijf..., qui restreint l'accès à ceux qui connaissent la chaîne exacte.
Du point de vue d'un malfaiteur qui souhaite accéder à cette ressource, ces approches sont-elles équivalentes? Sinon, qu'est-ce qui les rend différents? Et en ce qui concerne la maintenabilité, y a-t-il des avantages et des inconvénients à l'une ou l'autre approche dont je devrais être conscient avant de mettre en œuvre l'une ou l'autre?
Une URL privée est quelque peu plus faible que l'authentification avec des informations d'identification, même si la taille en bits de l'URL est la même que celle des informations d'identification. La raison en est que l'URL peut plus facilement "fuir". Il est mis en cache dans le navigateur, connecté au serveur, etc. Si vous avez des liens sortants, l'URL privée peut apparaître dans l'en-tête du référent sur d'autres sites. (Il peut également être vu par des personnes regardant par-dessus votre épaule.)
S'il fuit (par accident ou par négligence de l'utilisateur), il peut finir par être public et même indexé par Google, ce qui permettrait à un attaquant de rechercher facilement toutes les URL ayant fui sur votre site!
Pour cette raison, les URL privées sont généralement utilisées uniquement pour des opérations ponctuelles telles que la réinitialisation de mot de passe, et elles ne sont généralement actives que pendant une durée limitée.
Il existe un fil conducteur sur la sécurité de l'information: Les URL aléatoires sont-elles un moyen sûr de protéger les photos de profil ? - une réponse partage cette histoire: Dropbox désactive les anciens liens partagés après que les déclarations de revenus se retrouvent sur Google . Ce n'est donc pas seulement un risque théorique.
Remarque:
Beaucoup de gens semblent confondre une URL "privée" avec l'authentification. En outre, il semble y avoir une certaine confusion que l'envoi du lien via une entité de confiance est une tentative d'authentification à deux facteurs. Pour être clair, nous parlons d'une ressource accessible au public, bien que suffisamment difficile à deviner.
Lorsque vous utilisez une URL privée, vous devez toujours supposer qu'elle peut être compromise - vous devez concevoir une telle URL de sorte que même si elle est compromise, la ressource ne divulguera pas d'informations à l'attaquant.
Les URL privées/difficiles à deviner ne sont pas équivalentes à l'authentification par mot de passe. Par nature, les URL privées ne sont pas du tout privées - ce sont des ressources accessibles au public. Je pense que le terme URL "privée" est impropre, ce sont plutôt des URL "obscures".
Il existe certains cas où l'utilisation d'une URL "privée" est acceptable, mais ils sont intrinsèquement moins sûrs que les méthodes d'authentification traditionnelles telles que l'authentification par mot de passe ou l'authentification par clé.
Certains des endroits où j'ai souvent vu des URL "privées" utilisées sont:
- E-mails de réinitialisation de mot de passe
- E-mails de génération de certificats
- E-mails de confirmation de compte/e-mail
- Livraison du contenu acheté (ebooks, etc.)
- Autres choses diverses comme l'enregistrement en vol, l'impression de la carte d'embarquement, l'utilisation d'URL privées en plus de l'authentification traditionnelle
Le point commun ici est que les URL aléatoires ne sont généralement bonnes que pour les opérations ponctuelles. De plus, l'authentification traditionnelle et les URL aléatoires ne s'excluent pas mutuellement - en effet, ils peuvent être utilisés conjointement pour fournir une sécurité supplémentaire lors de la livraison d'une ressource.
Comme l'a souligné Robert Harvey, la seule façon d'utiliser en toute sécurité une URL aléatoire/privée est de générer la page de manière dynamique et de soumettre l'URL à l'utilisateur de telle sorte que l'utilisateur puisse être considéré comme semi-authentifié. Cela peut être un e-mail, un SMS, etc.
Une URL générée de manière aléatoire/privée a généralement quelques propriétés:
- Il devrait expirer après un délai raisonnable
- Il doit s'agir d'une URL à usage unique: IE elle doit expirer après le premier accès.
- Il doit reporter l'authentification de l'utilisateur à une autre entité à laquelle il fait confiance pour authentifier l'utilisateur en toute sécurité. (En envoyant le lien par e-mail ou SMS, etc.)
- Il devrait être impossible pour un ordinateur moderne de forcer brutalement l'URL dans le délai précédant l'expiration - soit en limitant le débit de l'API qui expose la ressource, soit en créant un point de terminaison d'URL avec une entropie suffisante de sorte qu'il ne puisse pas être deviné.
- Il ne doit pas divulguer d'informations sur l'utilisateur. IE: Si la page doit réinitialiser un mot de passe: la page ne doit pas afficher les informations de compte du demandeur. Si Alice demande un lien de réinitialisation de mot de passe et que Bob devine d'une manière ou d'une autre l'URL, Bob ne devrait avoir aucun moyen de savoir à quel mot de passe il réinitialise.
- S'il fait fuir des informations sur l'utilisateur, il doit être utilisé en plus de l'authentification traditionnelle, par exemple une page peut considérer un utilisateur authentifié s'il a un cookie ou si son identifiant de session est toujours valide.
Différentes ressources nécessitent différents niveaux de sécurité. Si vous souhaitez partager une recette secrète avec des amis, par exemple, il serait acceptable d'utiliser une URL aléatoire/privée pour la partager avec eux. Cependant, si la ressource pouvait être utilisée pour voler l'identité de quelqu'un ou compromettre ses comptes avec d'autres fournisseurs de services, vous vous soucieriez probablement beaucoup plus de restreindre l'accès à cette ressource.
Presque tous les schémas d'authentification se résument à prouver que vous connaissez un secret. Vous vous authentifiez auprès d'un service en prouvant que vous connaissez un mot de passe secret, ou une URL secrète ou, ...
Certains protocoles plus avancés (par exemple, OAUTH, Kerberos, ...) vous permettent de prouver que vous connaissez le secret sans réellement transmettre le secret. Ceci est important car il existe plus de moyens d'obtenir un secret "non devinable" que de le deviner.
Je pourrais être assis dans le même cybercafé que vous, écoutant votre connexion Wi-Fi lorsque vous tapez votre URL "impossible à deviner". À ce stade, si vous n'utilisiez pas SSL ou si je peux exploiter le dernier nouveau bogue de votre implémentation SSL, je connais votre secret également.
Beaucoup de bonnes réponses déjà dans ce fil, mais pour répondre directement à la question:
Du point de vue d'un malfaiteur qui souhaite accéder à cette ressource, ces approches sont-elles équivalentes? Sinon, qu'est-ce qui les rend différents?
Permettez-moi d'établir une définition. L '"authentification" consiste à fournir des informations d'identification pour prouver une revendication d'identité. Le contrôle d'accès est généralement basé sur l'identification de l'utilisateur.
Votre URL secrète n'est pas liée à un utilisateur spécifique. Comme d'autres l'ont souligné, il pourrait se retrouver dans le fichier journal d'un proxy, ou dans une demande de recherche indexée par Google, ou de nombreuses autres manières de s'échapper.
D'un autre côté, un mot de passe est lié à un compte utilisateur unique. Vous avez la possibilité de le réinitialiser, ou de l'autoriser uniquement à être utilisé à l'emplacement d'origine de l'utilisateur, ou à l'adresse IP connue, ou à tout autre nombre de contrôles.
Un nom d'utilisateur/mot de passe vous donne un contrôle beaucoup plus précis de l'accès.
Le contrôle d'accès permet à une identité (sujet) d'accéder à une ressource (objet). Dans votre exemple d'URL, l'identité est "toute personne qui obtient l'URL, par quelque moyen que ce soit".
Allez avec le nom d'utilisateur/mot de passe si vous le pouvez. Les URL fuient de toutes sortes de façons inattendues au fil du temps.
Un autre élément qui n'est noté nulle part est la limitation des "suppositions". Pour la plupart des systèmes d'authentification par mot de passe, vous obtenez un nombre limité de tentatives pour deviner un mot de passe pour un utilisateur avant que d'autres tentatives d'authentification ne soient verrouillées ou limitées.
Bien que vous puissiez faire quelque chose de similaire avec des "suppositions" contre votre schéma d'URL, il serait un peu plus difficile à mettre en œuvre. S'il existe un modèle reconnaissable dans votre génération d'URL, il peut être difficile d'empêcher quelqu'un de se configurer pour se frayer un chemin à travers votre espace URL "aléatoire".
Une URL secrète est tout aussi sécurisée qu'un mot de passe secret. Cependant, les mots de passe sont plus faciles à garder secrets que les URL, car tout le monde et ses programmes savent que les mots de passe doivent rester secrets.
Par exemple, votre navigateur n'affichera pas de mot de passe à l'écran, stockera uniquement les mots de passe avec votre permission et offrira des moyens de protéger ce stockage de mot de passe (tel que le stockage crypté déverrouillé par un mot de passe principal). En revanche, il affichera toujours les URL à l'écran, peut éventuellement les divulguer via l'en-tête du référent et les stocker automatiquement dans votre historique de navigation sans aucune protection supplémentaire.
De même, les proxys HTTP n'enregistrent généralement pas les mots de passe, tandis que les URL sont généralement enregistrées.
L'utilisation d'URL pour l'authentification signifie également que le partage d'URL partage l'authentification, ce qui rend difficile la révocation (ou l'enregistrement) individuel de l'accès.
Et bien sûr, les URL secrètes héritent de toutes les faiblesses des mots de passe secrets. En particulier, l'utilisation d'un mot de passe pour l'authentification révélera ce mot de passe au serveur et à toute personne capable de lire votre communication.
Il y a un autre aspect que je n'ai pas encore vu mentionné - les raccourcisseurs d'URL.
Dans une publication récente (avril 2016), il a été affirmé que les services de raccourcissement d'URL annulent complètement la sécurité accrue fournie par les URL "non devinables" générées de manière aléatoire. L'espace URL du service raccourci est considérablement plus petit que votre URL générée aléatoirement - ce qui signifie que toute URL "sécurisée" partagée avec un service raccourcisseur peut être devinée plus facilement que prévu.
Pour illustrer - supposons que votre URL aléatoire est de 128 bits (c'est-à-dire un guid). Supposons également que votre générateur de nombres aléatoires est vraiment fort et que vous générez ces bits de manière uniforme. Deviner un nombre 128 bits est très difficile et peut prendre un temps considérable - votre URL est effectivement protégée par une clé 128 bits.
Supposons ensuite que quelqu'un a partagé cette URL sur le raccourcisseur d'URL Google. Aujourd'hui, ce service émet un identifiant de 10 caractères, composé de lettres et de chiffres. (26 + 10) ^ 10 ~ = 3,6 * 10 ^ 15 <2 ^ 52 - nous avons donc réduit de moitié la force des touches de 128 bits à 52 bits.
Ajoutez à cela que les générateurs n'utilisent pas tout l'espace en raison d'autres considérations et vous pouvez monter une attaque efficace qui combine la force brute avec des canaux latéraux (probablement des tampons d'URL aléatoires pré-alloués).
L'article d'origine: http://arxiv.org/pdf/1604.02734v1.pdf
Un article de blog résumant l'article (par l'auteur): https://freedom-to-tinker.com/blog/vitaly/gone-in-six-characters-short-urls-considered -services-pour-cloud /