Resumen

  • El HTML actual de WHOIS Crypt ordena enviar por POST un control type="text" cuyo nombre es plaintextpassword a una acción relativa en el propio origen de AFRINIC. Esta investigación no rellenó ni envió el formulario.
  • El hash resultante no prueba la custodia de la entrada. La guía de miembros dice que solo debe compartirse el hash con AFRINIC y que el miembro debe guardar la contraseña en claro; el paso intermedio necesita una explicación verificable.

Hay tres objetos distintos en el clic que genera un hash. Está la contraseña que una persona escribe, está el trayecto por el que se procesa y está la cadena BCRYPT que aparece al final. La página de AFRINIC explica el tercero. El control institucional más importante está en el segundo.

La ruta pública comienza en la página de utilidades WHOIS, que presenta el generador BCRYPT-PW y enlaza con la aplicación WHOIS Crypt. El código HTML capturado el 14 de septiembre de 2026 permite reconstruir la instrucción sin ejecutar nada. El formulario se llama myForm, usa method="POST" y tiene la acción relativa ?lang=en#cli. El campo rotulado “Password” no se declara como type="password", sino como type="text". Su identificador y el nombre que viajaría en la solicitud son plaintextpassword. Después aparece el botón “Generate hash”.

No introdujimos una contraseña. No usamos una cuenta, no enviamos una solicitud, no observamos tráfico y no alteramos un objeto de la base WHOIS. Lo que existe es una instrucción publicada. La norma HTML define los formularios como controles cuyos datos pueden enviarse a un servidor para su procesamiento y muestra parámetros en el cuerpo de un POST como patrón habitual. Si una persona activa este formulario tal como está declarado, el navegador debe resolver la acción en el mismo origen whois-web.afrinic.net y entregar allí el valor de aplicación del campo.

La precisión verbal importa. Ese valor es “texto en claro” antes de convertirse en hash, pero no hay base para llamarlo texto legible sobre la red. La URL usa HTTPS. TLS protege el intercambio frente a escucha y manipulación durante el transporte. El candado, por tanto, es evidencia favorable. Aun así, cifra el camino hacia un receptor; no convierte ese receptor en una función que solo corre dentro del dispositivo del miembro.

Es posible que el servidor reciba la contraseña durante milisegundos, calcule BCRYPT y la descarte sin dejar copia alguna. También es posible que alguna capa genérica registre un cuerpo, una excepción o una traza. Los documentos públicos capturados no permiten escoger entre esos escenarios. Decir “el formulario recibe” no equivale a decir “el sistema conserva”. El propósito de un recibo operativo es impedir que esa diferencia dependa de la imaginación del lector.

La guía de referencia para miembros de AFRINIC pone el listón con una frase concreta. Al describir el objeto mantenedor, recomienda generar un hash BCRYPT de la contraseña en claro. Añade que solo el hash debe compartirse con AFRINIC y que el miembro debe guardar de forma segura la contraseña. La recomendación puede referirse estrictamente al contenido que se entrega para el atributo auth:: la base recibe el verificador, no el secreto. Si esa es la intención, no excluye necesariamente un generador remoto. Pero el formulario enlazado crea un contacto previo con un endpoint de AFRINIC que la frase no distingue.

Esa tensión es más útil que una acusación. No demuestra una infracción, un incidente de privacidad ni una promesa falsa. Demuestra que la palabra “compartir” necesita un alcance. ¿Quiere decir que la contraseña no se almacena en el objeto WHOIS? ¿Que no se conserva después del cálculo? ¿O que nunca abandona el equipo del miembro? Son controles diferentes y exigen arquitecturas diferentes.

El tipo del campo añade una decisión visible. Según HTML, type="password" representa información sensible mediante un control que oculta la entrada. type="text" ofrece un control de texto ordinario. El formulario observado elige este último. Eso no acredita que alguien haya visto la pantalla ni que la contraseña se haya filtrado. Tampoco dice nada sobre el coste o la sal de BCRYPT. Solo muestra que el navegador no recibe la instrucción semántica de ocultar la entrada. Cambiar el tipo sería una mejora de presentación, no una solución completa de custodia.

También hay código con capacidad en el documento. La página carga Turnstile desde challenges.cloudflare.com, además de jQuery, Mustache y un main.js local. OWASP explica por qué el JavaScript de terceros constituye una frontera: el proveedor puede cambiar código y el código que se ejecuta en la página puede tener acceso al contexto del documento. Ese marco no es una constatación sobre Cloudflare. Ver Turnstile en el HTML no prueba que haya leído, recibido o extraído plaintextpassword.

El main.js enlazado ayuda a limitar otra inferencia. En la copia exacta revisada no aparecen myForm, plaintextpassword, BCRYPT ni un controlador de este generador. El script inicializa una vista distinta cuando encuentra create-container; maneja la carga, edición y guardado de objetos WHOIS, con selectores y una operación de guardado propios. No es evidencia de que el campo Crypt se transforme localmente antes de enviar el formulario. Tampoco demuestra que ninguna otra biblioteca, respuesta dinámica, extensión o rutina del servidor intervenga.

El mapa probado es, por tanto, corto. Existe un campo visible, una acción POST al mismo origen, una URL HTTPS y un conjunto de scripts declarados. Falta el controlador del servidor, la política del proxy, la configuración de observabilidad y un inventario de quién puede acceder a la preimagen. Una evaluación responsable se detiene ahí. No convierte lo desconocido en una vulnerabilidad.

La política de privacidad de AFRINIC ofrece contrapesos reales. Presenta a AFRINIC como responsable del tratamiento, enumera los servicios WHOIS entre las fuentes de recopilación, reserva el acceso a personal designado, menciona obligaciones para terceros y relaciona la retención con fines organizativos o legales. Es una política general. No especifica si el campo del generador se excluye de los registros, si el cuerpo llega a herramientas de análisis, cuál es la vida de la contraseña en memoria o si el script externo está aislado de ese control.

El registro de eventos es la prueba más directa. La guía de OWASP sobre logging coloca las contraseñas de autenticación entre los datos que normalmente no deben grabarse de forma directa. Cuando un evento necesita registro, propone eliminar, enmascarar, sanear, hashear o cifrar el material sensible. No inspeccionamos ningún registro de AFRINIC. Precisamente por eso la pregunta puede formularse sin fingir un resultado: ¿una prueba autorizada con un valor sintético confirma que plaintextpassword está ausente de logs de aplicación, proxy, errores, trazas, analítica y soporte?

BCRYPT no puede contestar. Su trabajo empieza con una entrada que ya existe en algún lugar. El algoritmo puede generar un verificador correcto y resistente mientras una capa anterior conserva la entrada por accidente. También puede operar en un servicio remoto bien diseñado que no retiene nada. La calidad del hash y la calidad del itinerario son propiedades independientes.

Una primera arquitectura coherente haría el cálculo en el navegador. Debería publicar el código revisable, fijar sus dependencias, separar los scripts de terceros del control sensible y demostrar que la solicitud saliente solo contiene el hash. Poner la palabra “local” en la interfaz no bastaría.

La segunda arquitectura conservaría el cálculo en servidor. La página explicaría que un endpoint de AFRINIC recibe por HTTPS una contraseña nueva y no reutilizada, la usa únicamente para calcular el hash, la elimina, la excluye de registros y trazas y limita el acceso de terceros. Este diseño no es ilegítimo por ser remoto. Se vuelve auditable al nombrar receptor, duración y copias prohibidas.

La guía debe reflejar esa elección. Si “solo el hash” describe únicamente el objeto final, hay que decirlo. Si describe todo el recorrido, el POST remoto debe desaparecer. En ambos casos, la instrucción más segura para el miembro es no escribir jamás una contraseña existente o reutilizada en una herramienta de prueba. Esta investigación tampoco lo hizo.

El recibo necesita además una versión y una fecha. El formulario, la integración de Turnstile, el proxy inverso, el recolector de errores y la plataforma de analítica pueden cambiar por separado. Una prueba realizada contra una combinación no debe certificar en silencio la siguiente. Después de un cambio material, un marcador sintético autorizado permite repetir el recorrido, enumerar componentes y registrar excepciones. No hace falta publicar el marcador ni la configuración interna; lo público debe ser la frontera comprobada y el momento al que corresponde.

Ese documento uniría tres capas que hoy se leen por separado. La política de privacidad distribuye responsabilidad general. La guía de miembros describe el manejo esperado de un maintainer. El recibo de ingeniería cuenta la vida de un campo concreto. Las tres pueden ser correctas y aun dejar un hueco entre ellas. Usar el mismo vocabulario para recibir, conservar y compartir convierte páginas dispersas en un solo contrato.

También separa garantía de observación. “No registramos contraseñas” es una garantía institucional. Confirmar que un marcador sintético falta en cada destino nombrado es una observación controlada. Ninguna prueba cubre para siempre todas las versiones, pero su combinación da al miembro algo verificable que el hash final, por sí solo, nunca podrá narrar.

Fuentes