Un lien court protégé par mot de passe est une URL courte qui demande un mot de passe avant d'envoyer quelqu'un plus loin. Vous ouvrez le lien, vous tombez sur une petite page interstitielle plutôt que sur la destination, vous tapez le mot de passe, et c'est seulement à ce moment que la redirection se déclenche. Entrez le mauvais mot de passe et vous restez sur l'invite. La destination n'est jamais exposée tant que la vérification ne passe pas.
C'est toute l'idée, et il vaut la peine d'être précis à ce sujet car le nom la survend. Un portail de mot de passe est une friction d'accès devant un lien. Ce n'est pas un chiffrement de la page derrière le lien. Ce sont des garanties différentes, et les confondre est la façon dont les gens finissent par être surpris plus tard. Cet article couvre à quoi le portail est utile, les cas d'usage qui s'y adaptent vraiment, comment la vérification fonctionne à la redirection, où la sécurité se termine, et avec quoi la combiner pour que l'ensemble tienne.
À quoi sert un lien court protégé par mot de passe#
Les cas utiles partagent une forme : vous partagez un lien via un canal que vous ne contrôlez pas entièrement, et vous voulez qu'une deuxième chose en plus de l'URL soit requise pour l'entrée.
Un document sensible est l'exemple évident. Vous envoyez un brouillon de contrat, un modèle financier ou un deck interne à quelqu'un en dehors de votre entreprise. Les emails sont transférés. Les PDFs sont renvoyés. Un lien court que n'importe qui avec l'URL peut ouvrir n'est aussi privé que la personne la moins prudente qui l'a jamais détenu. Mettez un mot de passe dessus et un transfert accidentel ne signifie plus un accès automatique.
Les livrables clients sont le même schéma avec une échéance attachée. Une agence remet un lot d'actifs, un montage vidéo, un rapport de campagne. Le client devrait y accéder, pas tout le carnet d'adresses du client. Une URL sécurisée garde le livrable derrière un secret partagé que vous définissez lors de la création du lien.
Les campagnes privées et le contenu sécurisé complètent la liste. Une page de destination pré-lancement que vous voulez qu'un petit groupe prévisualise. Une offre d'accès anticipé pour une liste d'attente. Une ressource réservée aux membres où l'audience a déjà un mot de passe quelque part. Dans chaque cas le lien voyage via email ou chat, et le mot de passe est ce qui sépare « j'ai reçu ça » de « j'ai trouvé ça par hasard ».
Ce qui ne convient pas : tout ce qui est vraiment secret, tout ce qui est réglementé, tout ce dont une fuite serait un incident à signaler. Pour ceux-là, un mot de passe de lien partagé est trop grossier. Vous voulez une authentification par personne sur la destination elle-même, ce qui est un contrôle différent et sur lequel je reviendrai.
Comment fonctionne un portail de mot de passe à la redirection#
Voici la partie mécanique, parce que l'ordre des opérations est ce qui rend le portail significatif.
Un lien court normal est une redirection. L'edge recherche le slug, trouve la destination, et écrit un 302 dans le navigateur du visiteur. Rapide, sans état, sans questions. Un lien court protégé par mot de passe insère une étape avant la redirection : l'edge voit que le lien a un mot de passe défini, donc au lieu de rediriger, il retourne un challenge. Le visiteur obtient une page interstitielle demandant le mot de passe. Il le soumet. La valeur soumise est vérifiée par rapport au hachage stocké. Si elle correspond, la redirection procède. Si ce n'est pas le cas, il reste sur l'invite et l'URL de destination n'est jamais envoyée à son navigateur.
Deux détails comptent pour que cela vaille quelque chose.
Premièrement, le mot de passe est haché, jamais stocké en clair. Le secret stocké d'un lien devrait être un hachage unidirectionnel pour qu'une lecture de base de données ne remette pas à un attaquant tous les mots de passe de lien du système. Argon2id est la recommandation actuelle pour le hachage de mots de passe, et c'est ce qu'Elido utilise pour les mots de passe de liens, avec la vérification effectuée en cours de processus en utilisant une comparaison en temps constant pour que la vérification elle-même ne fuite pas d'informations par timing. L'API pour un lien ne retourne jamais le hachage ; elle retourne un booléen qui indique si un mot de passe est défini. Un destinataire frappant un lien protégé obtient un 401 avec un drapeau password_required et un token de challenge, et doit soumettre le bon mot de passe dans une requête de suivi avant que la redirection se produise. La mécanique de ce stockage est exposée dans la liste de contrôle de sécurité pour les raccourcisseurs d'URL, section sur la protection des liens par mot de passe.
Deuxièmement, la vérification se produit avant que la destination soit révélée. Cela semble évident, mais un nombre surprenant de schémas de liens « privés » divulguent la destination dans du code côté client ou une chaîne de redirection qu'un visiteur déterminé peut lire sur le réseau. Le but de faire la vérification à la redirection, côté serveur, est que l'URL de destination reste sur le serveur jusqu'à ce que le mot de passe soit correct. Si vous avez déjà vu un portail implémenté en JavaScript qui récupère la vraie URL puis redirige, vous avez vu un portail que n'importe qui avec les outils de développement du navigateur peut traverser directement. L'évaluation côté serveur est la différence - le même raisonnement qui fait que les smart links routent à l'edge plutôt que dans un shim JS sur une page d'atterrissage.
Les limites de sécurité, dites clairement#
C'est la section que les gens sautent puis regrettent, donc elle se trouve au milieu où elle est difficile à manquer.
Un portail de mot de passe protège le lien court. Il ne protège pas la destination. Si la destination est une URL publique que n'importe qui peut atteindre en la tapant directement, alors le mot de passe ne fait que stopper les personnes qui ont le lien court, pas les personnes qui peuvent deviner ou tomber sur la page sous-jacente. Le portail élève la barre pour le cas de partage courant, où tout ce que quelqu'un a est l'URL courte. Il ne fait rien pour une destination déjà exposée.
Donc la règle est simple : la destination devrait aussi être contrôlée en accès. Un document derrière un lien court protégé par mot de passe devrait aussi vivre quelque part qui vérifie qui vous êtes, pas simplement quelque part qui a un long chemin impossible à deviner. Le Guide OWASP sur les mots de passe et le guide de contrôle d'accès associé sont la référence ici : l'authentification prouve qui est quelqu'un, le contrôle d'accès décide ce qu'il peut atteindre, et un mot de passe de lien partagé est une forme faible du premier qui ne dit rien du second. Utilisez-le comme couche de commodité, pas comme la chose qui se dresse entre un attaquant et des données réglementées.
Quelques autres limites honnêtes.
Un mot de passe partagé est partagé. Toute personne qui l'a est la même identité pour le portail. Il n'y a pas de trace par personne de qui a ouvert le lien, pas de moyen de révoquer l'accès d'une personne sans faire tourner le mot de passe pour tout le monde. Si vous avez besoin de savoir que Dana spécifiquement a ouvert le livrable, un mot de passe de lien partagé ne vous le dira pas.
Le lien devrait être servi sur HTTPS, toujours. Un mot de passe soumis sur HTTP en clair est un mot de passe envoyé en clair à quiconque se trouve sur le chemin réseau. Le chiffrement de transport est le minimum, pas une fonctionnalité ; l'aperçu MDN de HTTPS explique pourquoi. Elido sert les redirections sur HTTPS par défaut, y compris sur les domaines personnalisés, mais le principe s'applique partout où vous mettez un portail.
Et un mot de passe n'est pas un substitut à l'expiration. Un lien qui reste actif indéfiniment est une responsabilité qu'il ait un mot de passe ou non, parce que le secret fuit lentement au fil du temps à mesure qu'il est collé dans de plus en plus d'endroits. Associez le portail à une durée de vie.
Avec quoi le combiner#
Un portail de mot de passe est un contrôle. Il fonctionne mieux empilé avec d'autres qui couvrent ce qu'il ne peut pas.
L'expiration et les plafonds de clics maximum limitent le lien dans le temps et l'utilisation. Définissez un expires_at pour qu'un livrable client disparaisse une fois l'engagement terminé, et un plafond de clics maximum pour qu'un lien de téléchargement à usage unique se désactive après avoir été ouvert une seule fois. Les deux sont appliqués à la redirection avant qu'un événement de clic soit enregistré, ce qui signifie qu'une tentative de mauvais mot de passe contre un lien déjà expiré n'atteint même jamais le portail. Les compromis autour de la durée de vie sont dans l'article expiration des liens et liens auto-destructeurs.
Les limites IP ou géographiques réduisent qui peut tenter le portail du tout. Si un livrable client ne s'ouvre jamais que depuis un seul bureau, restreindre le lien à cette plage signifie qu'un mot de passe divulgué plus un lien divulgué échoue quand même depuis n'importe quel autre endroit. Les contrôles au niveau de la région sont couverts dans l'article liens courts avec géo-ciblage, et ils se combinent avec le mot de passe plutôt que de le remplacer.
Pour les équipes, la bonne réponse n'est généralement pas un mot de passe partagé du tout. C'est le SSO. Quand les personnes qui devraient accéder à un lien sont des employés dans votre fournisseur d'identité, sécurisez la destination derrière SCIM et SSO pour que l'accès suive l'annuaire : quelqu'un quitte l'entreprise, son accès est supprimé, pas de rotation de mot de passe requise. Un mot de passe de lien partagé est pour le partage externe ad hoc ; l'accès géré par annuaire est pour tout ce où vous avez besoin de révocation par personne. Le guide de configuration SCIM et SSO explique comment le mettre en place, et la page des solutions entreprise couvre où cela s'inscrit.
Le principe général est la défense en couches. Aucun contrôle ici n'est fort à lui seul. Un mot de passe arrête l'accès occasionnel, l'expiration borne la fenêtre, HTTPS protège le réseau, le contrôle d'accès de la destination protège le contenu, et SSO gère le cas de l'équipe. Empilez ceux dont votre situation a besoin.
Un guide pratique#
Si vous voulez sécuriser un lien, la forme du travail est la même quel que soit l'outil.
Définissez le mot de passe quand vous créez ou modifiez le lien. Les paramètres du lien devraient vous permettre d'y attacher un mot de passe ; une fois défini, le lien cesse d'être une redirection simple et commence à retourner le challenge. Choisissez un mot de passe qui n'est pas trivialement devinable et qui n'est pas réutilisé d'ailleurs, car un secret partagé qui déverrouille aussi votre email est un mauvais secret partagé.
Partagez le lien et le mot de passe par des canaux séparés. C'est l'habitude à la valeur ajoutée la plus élevée. Envoyez le lien court dans l'email ou le document, et envoyez le mot de passe via un message de chat, un email séparé ou un appel rapide. Si les deux voyagent dans le même message, un seul message intercepté livre tout, et le portail ne vous a rien apporté. Les séparer signifie qu'un attaquant a besoin de deux canaux, pas un seul.
Définissez une expiration en même temps. Décidez à l'avance combien de temps le lien devrait vivre et s'il devrait se plafonner après un nombre connu d'ouvertures, et définissez-les quand vous le créez plutôt que de vous promettre que vous nettoierez plus tard. Vous ne le ferez pas.
Vérifiez que la destination a son propre contrôle d'accès si le contenu est sensible. Le portail fait son travail pour le cas de partage. Si le document sous-jacent doit aussi résister à quelqu'un qui devine l'URL, cette protection doit vivre sur la destination, pas sur le lien court. Pour un traitement plus complet de la façon dont ces pièces s'intègrent dans un modèle de menace, les raccourcisseurs d'URL sont-ils sûrs parcourt la vue d'ensemble plus large, et la page de confiance couvre la posture d'Elido.
C'est la version honnête des liens courts protégés par mot de passe. Ils sont un moyen utile et à faible friction de garder une URL partagée d'être ouverte par quiconque la reçoit. Ce ne sont pas un coffre-fort. Utilisés comme une couche dans une pile, avec l'expiration et une destination correctement contrôlée en accès, ils font exactement le travail pour lequel ils sont faits. Utilisés comme la seule chose entre un attaquant et quelque chose d'important, ils vous décevront. Définissez le portail, séparez les canaux, bornez la durée de vie, et verrouillez la destination, et vous avez un flux de partage qui tient.
Si vous voulez voir quels contrôles atterrissent sur quel plan, la page de tarification les liste, et la fonctionnalité des domaines personnalisés couvre le service de liens sécurisés sur votre propre domaine brandé sur HTTPS. La configuration est couverte dans comment configurer des liens courts brandés.