Les URL privées non identifiables sont-elles équivalentes à l'authentification par mot de passe?

Je veux 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 d' authentification basée sur un mot de passe . Par exemple, je ne pouvais autoriser l'accès à la ressource que par l'intermédiaire d'un serveur Web vérifiant les informations d'identification des demandes entrantes (par exemple, par rapport à une base de données d'utilisateurs sauvegardée) avant de servir le fichier.

Alternativement, je pourrais simplement utiliser une URL privée . C'est-à-dire que je pourrais simplement héberger la ressource selon un chemin impossible à deviner, par exemple https://example.com/23idcojj20ijf..., ce qui restreindrait l'accès à ceux qui connaissent la chaîne exacte.

Du point de vue d'un malfaiteur qui veut accéder à cette ressource, ces approches sont-elles équivalentes? Si non, qu'est-ce qui les rend différents? Et en ce qui concerne la facilité de maintenance, existe-t-il des avantages et des inconvénients à l'une ou l'autre approche à connaître avant de mettre en œuvre l'une ou l'autre?

Une URL privée est un peu plus faible qu'une authentification avec informations d'identification, même si la taille en bits de l'URL est identique à celle des informations d'identification. La raison en est que l'URL peut plus facilement "fuir". Il est mis en cache dans le navigateur, enregistré sur le 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.)

En cas de fuite (par accident ou par négligence de la part de l'utilisateur), il pourrait devenir public et même indexé par Google, ce qui permettrait à un attaquant de rechercher facilement toutes les URLs de votre site qui ont été filtrés!

Pour cette raison, les URL privées ne sont généralement utilisées que pour des opérations ponctuelles, telles que la réinitialisation de mots de passe, et ne sont généralement actives que pour une durée limitée.

Il existe un fil conducteur sur le site Sécurité de l'information: les URL aléatoires constituent-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 une fois que les déclarations de revenus sont terminées sur Google . Ce n'est donc pas simplement 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 quant au fait 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, même si elle est suffisamment difficile à deviner.

Lorsque vous utilisez une URL privée, vous devez toujours supposer que celle-ci peut être compromise - vous devez concevoir une telle URL de sorte que même si elle est compromise, la ressource ne transmettra 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 - elles sont des ressources accessibles au public. Je pense que le terme URL "privée" est un terme impropre, mais plutôt "obscur".

Dans certains cas, l’utilisation d’une URL "privée" est acceptable, mais elles sont intrinsèquement moins sécurisées que les méthodes d’authentification traditionnelles telles que l’authentification par mot de passe ou l’authentification par clé.

Voici quelques exemples d'URL "privées" couramment utilisées:

1. Mot de passe réinitialiser les emails
2. Email de génération de certificat
3. Email de confirmation de compte / email
4. Livraison du contenu acheté (ebooks, etc.)
5. Autres choses diverses comme l'enregistrement de 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 conviennent généralement que pour des opérations ponctuelles. En outre, l'authentification traditionnelle et les URL aléatoires ne s'excluent pas mutuellement . En fait, elles peuvent être utilisées conjointement pour renforcer la sécurité lors de la livraison d'une ressource.

Comme Robert Harvey l'a souligné, le seul moyen d'utiliser de manière sécurisée 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 manière à ce qu'il puisse être considéré comme semi-authentifié. Cela pourrait être un email, SMS, etc.

Une URL privée / générée aléatoirement a généralement quelques propriétés:

1. Il devrait expirer après un délai raisonnable
2. Il devrait s'agir d'une URL à usage unique: IE, elle devrait expirer après le premier accès.
3. Il doit reporter l'authentification de l'utilisateur à une autre entité en laquelle il fait confiance pour l'authentifier de manière sécurisée. (En envoyant le lien par e-mail ou SMS, etc.)
4. 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 url avec une entropie suffisante pour ne pas le deviner.
5. Il ne devrait pas y avoir de fuites d'informations sur l'utilisateur. IE: si la page doit réinitialiser un mot de passe: la page ne doit pas afficher les informations du compte du demandeur. Si Alice demande un lien de réinitialisation de mot de passe et que Bob devine l’URL, Bob ne devrait avoir aucun moyen de savoir quel mot de passe il réinitialise.
6. En cas de fuite d'informations sur l'utilisateur, il convient de l'utiliser en plus de l'authentification traditionnelle. Par exemple, une page peut considérer un utilisateur authentifié s'il possède 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. Toutefois, si la ressource pouvait être utilisée pour voler l’identité d’une personne ou compromettre ses comptes avec d’autres fournisseurs de services, il serait probablement plus important de restreindre l’accès à cette ressource.

Pratiquement tous les schémas d'authentification se résument à prouver que vous connaissez un secret. Vous vous authentifiez auprès de certains services en prouvant que vous connaissez un mot de passe secret, une URL secrète ou ...

Certains protocoles plus avancés (par exemple, OAUTH, Kerberos, ...) vous permettent de prouver que vous connaissez le secret sans le transmettre réellement . Ceci est important car il y a plus de façons d'obtenir un secret "impossible à deviner" en plus de le deviner.

Je pourrais être assis dans le même cybercafé que vous, espionnant votre connexion WiFi lorsque vous saisissez votre URL "indestructible". À ce stade, si vous n’utilisiez pas SSL ou si je pouvais exploiter le dernier bogue de votre implémentation SSL, je connaîtrais également votre secret.

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 veut accéder à cette ressource, ces approches sont-elles équivalentes? Si non, qu'est-ce qui les rend différents?

Permettez-moi d'établir une définition. "Authentification" est la fourniture d'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 fait remarquer, cela pourrait se retrouver dans le fichier journal d'un proxy, dans une requête de recherche indexée par Google ou dans de nombreuses autres manières.

D'autre part, un mot de passe est lié à un compte d'utilisateur unique. Vous avez la possibilité de le réinitialiser ou de ne l’autoriser que depuis le domicile de l’utilisateur, son adresse IP connue ou un nombre quelconque de contrôles.

Un nom d'utilisateur / mot de passe vous donne un contrôle beaucoup plus granulaire de l'accès.

Le contrôle d'accès permet à une identité (un sujet) d'accéder à une ressource (un objet). Dans votre exemple d'URL, l'identité est "quiconque 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 manières inattendues au fil du temps.

Une URL secrète est 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’affiche pas de mot de passe à l’écran, ne stocke que les mots de passe avec votre permission et offre des moyens de protéger le stockage de ce mot de passe (tel que le stockage chiffré déverrouillé par un mot de passe principal). En revanche, il affichera toujours les URL à l’écran, pourrait les fuir par 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 mandataires HTTP ne consignent généralement pas les mots de passe, alors que les URL sont généralement consignées.

L'utilisation des URL pour l'authentification signifie également que le partage d'URL partage l'authentification, ce qui rend difficile la révocation (ou l'enregistrement) d'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.

Un autre élément non noté nulle part est la limitation des «suppositions». Pour la plupart des systèmes d'authentification par mot de passe, vous avez peu d'essais de deviner le mot de passe d'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" sur votre schéma d'URL, il serait un peu plus difficile à mettre en œuvre. S'il existe un motif reconnaissable dans votre génération d'URL, il peut s'avérer difficile d'empêcher une personne en train de se préparer pour se frayer un chemin dans votre espace URL "aléatoire".

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 raccourcisseur d'URL annulaient complètement la sécurité accrue fournie par les URL "indestructibles" générées aléatoirement. L'espace URL du service shorterner est considérablement plus petit que votre URL générée aléatoirement - ce qui signifie qu'une telle URL "sécurisée" partagée avec un service de raccourcisseur peut être devinée plus facilement que prévu.

Pour illustrer notre propos, supposons que votre URL aléatoire ait une longueur de 128 bits (c’est-à-dire un guid). En outre, supposons que votre générateur de nombres aléatoires soit très puissant et que vous génériez ces bits de manière uniforme. Deviner un numéro 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 ait partagé cette URL sur le raccourcisseur d'URL de Google. Aujourd'hui, ce service émet un identifiant long 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é l'intensité de la clé de 128 bits à 52 bits.

Ajoutez à cela le fait que les générateurs n'utilisent pas l'intégralité de l'espace pour d'autres raisons et vous pouvez monter une attaque efficace qui combine la force brute avec des canaux secondaires (le plus souvent des tampons d'URL aléatoires pré-alloués).

L'article original: http://arxiv.org/pdf/1604.02734v1.pdf
Un article de blog résumant l'article (rédigé par l'auteur): https://freedom-to-tinker.com/blog/vitaly/gone-in- urls courts à six caractères considérés comme nuisibles pour les services de cloud computing /