Dos cosas muy diferentes llamadas "protección HTML con contraseña"
Cuando la gente busca "proteger un archivo HTML con contraseña", acaba en tutoriales que caen en una de dos categorías, y la distinción importa mucho. La primera categoría es del lado del cliente: un fragmento de JavaScript embebido en el archivo que muestra un prompt pidiendo una contraseña. La segunda es del lado del servidor: el servidor que hospeda el archivo se niega a servirlo hasta que la contraseña coincide. El lado del cliente es ofuscación. El lado del servidor es protección. Los tutoriales rara vez lo dejan claro.
Por qué la "protección" del lado del cliente es frágil
Una verificación de contraseña JavaScript funciona así: cuando la página carga, un script pide una contraseña, la compara con un valor almacenado y revela el cuerpo si coincide. El problema es que todo lo que sabe el navegador, lo sabe el usuario. Clic derecho, ver código fuente, y todo el HTML (incluida la verificación de contraseña) es visible.
Úsalo cuando: la protección es decorativa, el público no es adversario y el contenido no es realmente sensible.
Opción 1, contraseña del lado del servidor de LiveSend
En LiveSend Pro, cada documento puede protegerse con una contraseña que estableces en el dashboard. La contraseña se hashea con bcrypt antes de almacenarla. Cuando un visitante accede a la URL, el servidor verifica la cookie. Si está ausente o no es válida, el servidor devuelve un prompt de contraseña y nunca envía el HTML del documento. Enviar la contraseña correcta establece una cookie de 24 horas. Esto es bloqueo del lado del servidor, el modelo que realmente mantiene el contenido fuera de manos no autorizadas.
Combínalo con el email gate (también en LiveSend Pro) para capturar el email del visitante en el primer desbloqueo. Así sabes no solo que el documento fue abierto, sino por quién.
Opción 2, contraseña de Tiiny.host
Tiiny.host ofrece protección con contraseña en sus planes de pago. El mecanismo es del lado del servidor, el mismo modelo que LiveSend en principio. Tiiny.host no incluye un email gate por visitante, así que obtienes recuentos de visitas agregados pero no puedes asociar una visita específica a un destinatario específico por defecto.
Opción 3, contraseña de Static.app
Static.app soporta bloqueo con autenticación básica para sitios estáticos en planes de pago. Está orientado a desarrolladores y el dashboard asume familiaridad con build artifacts y herramientas CLI, pero la protección subyacente es bloqueo real del lado del servidor.
Opción 4, cifrar el archivo con una herramienta de terceros
Herramientas como PageCrypt cifran el cuerpo HTML con una contraseña y lo embeben dentro de una página envolvente. La página envolvente pide la contraseña al cargar y descifra el cuerpo localmente con WebCrypto. Útil para distribución offline (puedes enviar el .html cifrado como adjunto de email, y solo alguien con la contraseña puede abrirlo). En la web abierta sigue siendo vulnerable a fuerza bruta offline si la contraseña es débil.
Cuándo las contraseñas no son la herramienta correcta
Las contraseñas añaden fricción pero no están vinculadas a una identidad. Si el destinatario reenvía la URL y la contraseña juntas, el siguiente visitante entra. Para transacciones con NDA, salas de datos de M&A o cualquier cosa donde importe el acceso vinculado a identidad, quieres una sala de datos virtual (DocSend Advanced, Firmex, Intralinks) en lugar de una contraseña en una página HTML estática.
Elegir la opción correcta
Trabajo confidencial real con clientes, quieres bloqueo del lado del servidor más seguimiento por visitante: LiveSend. Solo necesitas contraseña en un sitio estático: Tiiny.host. Cifrado para distribución offline: PageCrypt o similar. Acceso vinculado a identidad para transacciones reguladas: una VDR real, no una contraseña.