Parece que WordPress (a través de HTTPS):
// setup-config.php
$secret_keys = wp_remote_get( 'https://api.wordpress.org/secret-key/1.1/salt/' );
Podría decirse que es un mal diseño, pero se puede entender de dónde proviene el diseño.
Podría decirse que es un mal diseño porque se basa en api.wordpress.org para generar claves aleatorias y mantenerlas en secreto. Si api.wordpress.org se ve comprometido, entonces los atacantes podrían organizar el registro de las claves que utilizan las nuevas instalaciones de Wordpress. Eso sería problemático.
(Sí, Wordpress podría enviarte un código fuente de puerta trasera, pero en principio eso lo puede detectar cualquiera que examine el código fuente, como has hecho. Por el contrario, si api.wordpress.org está grabando en secreto una copia de las claves envía a nuevas instalaciones de Wordpress, que no es detectable por ninguna cantidad de inspección de código fuente o cualquier otro mecanismo disponible para terceros interesados.)
Es comprensible, ya que es difícil generar aleatoriedad de calidad criptográfica de forma independiente de la plataforma.
Podría decirse que todavía es un poco descuidado / perezoso. Podría decirse que un mejor diseño hubiera sido recopilar cierta aleatoriedad local (si es posible), recopilar cierta aleatoriedad de api.wordpress.org , y luego mezclar las dos de forma segura utilizando una función criptográfica hash. De esa manera, estará seguro siempre que cualquiera de estos dos valores sea bueno. Un compromiso de api.wordpress.org no pondría en peligro las instalaciones de Wordpress que se ejecutan en cualquier plataforma en la que el código pueda reunir cierta aleatoriedad local; solo pondría en peligro a la pequeña minoría de instalaciones que no pudieron obtener una buena aleatoriedad.
¿Cómo se puede generar una buena aleatoriedad de calidad criptográfica, a partir de fuentes locales? Hay varias maneras:
Lee 16 bytes de /dev/urandom , si existe.
Llame a openssl_random_pseudo_bytes() , que invoca OpenSSL para obtener crypto- calidad pseudoaleatoria bits .
Llame a mcrypt_create_iv() , con el indicador MCRYPT_DEV_URANDOM .
Por supuesto, uno puede probar todas las opciones disponibles y mezclar todo lo que obtiene. Siempre que al menos una de estas opciones funcione, serás bueno. Y, por supuesto, si combina esto con la salida de api.wordpress.org usando una función criptográfica, nunca será peor que el enfoque de hoy, y será mejor si api.wordpress.org alguna vez se vea comprometido.
Entonces, la combinación de aleatoriedad local y remota hubiera sido un mejor enfoque. Desafortunadamente, eso requiere un poco más de trabajo y un poco más de código. Quizás los desarrolladores tomaron el enfoque más fácil de solo consultar api.wordpress.org . Uno podría debatir la decisión de diseño, pero puede comprender cómo se podría haber elegido este enfoque.
Sin embargo, en general, como argumenta Thomas Pornin, este no es probablemente el mayor riesgo de seguridad con Wordpress. Estamos hablando de software con un largo historial de vulnerabilidades de seguridad. Por lo tanto, el riesgo incremental agregado por este aspecto de su generación de números aleatorios puede ser pequeño, en comparación con el riesgo que ya está tomando de cualquier manera.
Consulte también Generación segura de números aleatorios en PHP para obtener más información sobre cómo generar aleatorios de calidad criptográfica números de PHP y ¿Sería seguro usar números aleatorios de random.org en una solución criptográfica? para más información sobre por qué no es una buena idea confiar en una fuente remota de números aleatorios para sus claves criptográficas.
La misma razón es muy difícil para generar su propia entropía, especialmente en una nube o entorno de alojamiento compartido.
Esencialmente, WordPress está diciendo que tienen más entropía que tú. ¡Probablemente tienen razón! Así que lo generan y lo devuelven.
Es un posible vector de ataque. Sin embargo, no creo que sea probable, porque si está dirigido, el atacante ya debe tener el control de su red para redirigir la llamada de DNS al servidor adecuado. ENTONCES, necesitan falsificar un certificado SSL. Dicho todo, altamente improbable.
La URL es: https://api.wordpress.org/secret-key/1.1/salt/
Por lo tanto, utiliza SSL. Incluso si los atacantes subvierten el DNS para redirigir esa llamada, aún tendrían que poseer de alguna manera un certificado de servidor válido que contenga el nombre api.wordpress.org . Como tal, es probable que sea difícil para los atacantes ejecutar un servidor de generación de claves falsas.
Por supuesto, el propio servidor de WordPress podría registrar todas las claves que generó y traicionarle. Sin embargo, tenga en cuenta que ya puede hacerlo al insertar puertas traseras en su software, que usted usa (incluso pueden llamar "vulnerabilidades" a las puertas traseras y afirmar de manera plausible que no lo hicieron a propósito). En ese sentido, ya estás confiando en la gente de WordPress; Con esta generación de claves del lado del servidor, solo sigues confiando en ellos. Personalmente, no me preocuparía demasiado (al menos, no tanto como el mero hecho de utilizar un marco basado en PHP con un largo historial de seguridad cuestionable).
Como señala @jrg, generar claves de forma segura puede ser un desafío en algunos entornos basados en la nube: una computadora obtiene aleatoriedad al medir eventos físicos desde el hardware; en una máquina virtual no hay hardware real para medir. Específicamente, algunos proveedores de nube crean instancias de máquinas mediante el uso de instantáneas de VM. Todas las máquinas que salen de una instantánea común comparten el mismo estado inicial, en particular cualquier semilla aleatoria. El uso de la generación de claves del lado del servidor evita ese problema.
Lea otras preguntas en las etiquetas encryption tls php