Puis-je protéger un fichier HTML par mot de passe sans serveur ?

Seulement avec des astuces côté client : une invite JavaScript qui vérifie le mot de passe, ou un outil comme PageCrypt qui chiffre le corps HTML et demande une phrase secrète pour le déchiffrer localement. Ce sont une vraie protection si l'attaquant n'a que le fichier, mais tout ce qui est servi sur le web ouvert peut être inspecté en affichant la source de la page ou en ouvrant les devtools du navigateur.

La protection par mot de passe JavaScript pour les fichiers HTML est-elle sécurisée ?

Non, pas quand le fichier est hébergé sur le web ouvert. Une vérification JavaScript est appliquée dans le navigateur, donc l'attaquant peut afficher la source de la page, trouver le mot de passe (ou le corps chiffré et la logique de déchiffrement) et récupérer le contenu. Le chiffrement de type PageCrypt est plus robuste car le corps lui-même est chiffré, mais il envoie quand même le texte chiffré à quiconque charge la page.

Comment fonctionne la protection par mot de passe de LiveSend ?

Le mot de passe est haché avec bcrypt et stocké avec le document. Quand un visiteur accède à l'URL, le serveur exige le mot de passe avant de retourner tout HTML. Un déverrouillage réussi définit un cookie de courte durée pour que le visiteur ne re-saisisse pas le mot de passe à chaque rafraîchissement. Le corps HTML n'est jamais envoyé au navigateur tant que le mot de passe ne correspond pas. C'est un blocage côté serveur, le seul modèle qui garde vraiment le contenu hors des mains non autorisées.

Puis-je définir une date d'expiration sur un lien HTML protégé par mot de passe ?

Oui sur les services qui le supportent. LiveSend vous laisse définir une date d'expiration indépendamment du mot de passe, après laquelle l'URL cesse de servir le document. Tiiny.host a des contrôles similaires sur les plans payants.

Et si le destinataire partage le mot de passe avec quelqu'un d'autre ?

Un mot de passe seul n'est pas lié à un destinataire. Si vous avez besoin d'un contrôle d'accès par destinataire, combinez le mot de passe avec un email gate qui capture l'email du visiteur à la première visite. LiveSend supporte les deux simultanément : le mot de passe est requis pour déverrouiller, et l'email gate enregistre quel email a ouvert le document.

Comment protéger un fichier HTML par mot de passe avant de le partager

Deux choses très différentes appelées "protection HTML par mot de passe"

Quand les gens recherchent "protéger un fichier HTML par mot de passe", ils tombent sur des tutoriels qui se divisent en deux catégories, et la distinction est très importante. La première catégorie est côté client : un extrait JavaScript embarqué dans le fichier qui affiche une invite demandant un mot de passe. La seconde est côté serveur : le serveur hébergeant le fichier refuse de le servir tant que le mot de passe ne correspond pas. Le côté client est de l'obfuscation. Le côté serveur est de la protection. Les tutoriels le précisent rarement.

Pourquoi la "protection" côté client est fragile

Une vérification de mot de passe JavaScript ressemble à ceci : quand la page se charge, un script demande un mot de passe, le compare à une valeur stockée et révèle le corps si ça correspond. Le problème est que tout ce que le navigateur sait, l'utilisateur le sait. Clic droit, afficher la source, et tout le HTML (incluant la vérification du mot de passe) est visible.

À utiliser quand :la protection est décorative, le public n'est pas adverse et le contenu n'est pas vraiment sensible.

Option 1, mot de passe côté serveur LiveSend

Sur LiveSend Pro, chaque document peut être protégé par un mot de passe que vous définissez dans le tableau de bord. Le mot de passe est haché avec bcrypt avant stockage. Quand un visiteur accède à l'URL, le serveur vérifie le cookie. S'il est absent ou invalide, le serveur retourne une invite de mot de passe et n'envoie jamais le HTML du document. Soumettre le bon mot de passe définit un cookie de 24 heures. C'est un blocage côté serveur, le modèle qui garde vraiment le contenu hors des mains non autorisées.

Combinez-le avec l'email gate (aussi sur LiveSend Pro) pour capturer l'email du visiteur au premier déverrouillage. Vous savez ainsi non seulement que le document a été ouvert, mais par qui.

Option 2, mot de passe Tiiny.host

Tiiny.host propose une protection par mot de passe sur ses plans payants. Le mécanisme est côté serveur, même modèle que LiveSend en principe. Tiiny.host n'inclut pas d'email gate par visiteur, donc vous obtenez des compteurs de vues agrégés mais ne pouvez pas associer une vue spécifique à un destinataire spécifique par défaut.

Option 3, mot de passe Static.app

Static.app supporte le blocage basic-auth pour les sites statiques sur les plans payants. Il est ciblé sur les développeurs et le tableau de bord suppose une familiarité avec les build artifacts et les outils CLI, mais la protection sous-jacente est un vrai blocage côté serveur.

Option 4, chiffrer le fichier avec un outil tiers

Des outils comme PageCrypt chiffrent le corps HTML avec une phrase secrète et l'embarquent dans une page wrapper. Le wrapper demande la phrase secrète au chargement et déchiffre le corps localement avec WebCrypto. Utile pour la distribution hors ligne (vous pouvez envoyer le .html chiffré comme pièce jointe email, et seul quelqu'un avec la phrase secrète peut l'ouvrir). Sur le web ouvert, il reste vulnérable à la force brute hors ligne si la phrase secrète est faible.

Quand les mots de passe ne sont pas le bon outil

Les mots de passe ajoutent de la friction mais ne sont pas liés à une identité. Si le destinataire transmet l'URL et le mot de passe ensemble, le visiteur suivant entre. Pour les transactions avec NDA, salles de données M&A ou tout ce où l'accès lié à l'identité importe, vous voulez une virtual data room (DocSend Advanced, Firmex, Intralinks) plutôt qu'un mot de passe sur une page HTML statique.

Choisir la bonne option

Travail client vraiment confidentiel, vous voulez un blocage côté serveur plus un tracking par visiteur : LiveSend. Juste besoin d'un mot de passe sur un site statique : Tiiny.host. Chiffrement pour la distribution hors ligne : PageCrypt ou similaire. Accès lié à l'identité pour des transactions réglementées : une VDR appropriée, pas un mot de passe.