Sembra che WordPress recuperi tutte le costanti di crittografia da remoto (via HTTPS):
// setup-config.php
$secret_keys = wp_remote_get( 'https://api.wordpress.org/secret-key/1.1/salt/' );
Questo è probabilmente un cattivo design, ma si capisce da dove viene il design.
È discutibilmente un cattivo design, perché fa affidamento su api.wordpress.org per generare chiavi casuali e tenerle segrete. Se api.wordpress.org viene compromesso, gli autori degli attacchi potrebbero organizzare la registrazione delle chiavi utilizzate dalle nuove installazioni di Wordpress. Sarebbe problematico.
(Sì, Wordpress potrebbe inviarti codice sorgente backdoor, ma ciò sarebbe rilevabile in linea di principio da chiunque esaminasse il codice sorgente - come hai fatto tu. Al contrario, se api.wordpress.org sta registrando segretamente una copia delle chiavi invia a nuove installazioni Wordpress, che non è rilevabile da alcuna quantità di ispezione del codice sorgente o da qualsiasi altro meccanismo disponibile per terze parti interessate.)
È comprensibile, perché è difficile generare casualità di cripto-qualità in modo indipendente dalla piattaforma.
È ancora discutibilmente un po 'trascurato / pigro. Probabilmente, un design migliore sarebbe stato quello di raccogliere un po 'di casualità locale (se possibile), raccogliere un po' di casualità da api.wordpress.org , e quindi mescolare i due in modo sicuro usando una funzione di hash crittografica. In questo modo, sarai sicuro finché uno di questi due valori è buono. Un compromesso di api.wordpress.org non metterebbe in pericolo le installazioni di Wordpress in esecuzione su qualsiasi piattaforma in cui il codice fosse in grado di raccogliere una casualità locale; metterebbe solo in pericolo la piccola minoranza di installazioni che non erano in grado di ottenere una buona casualità.
Come si può generare una buona casualità a cripto-qualità, da fonti locali? Ci sono vari modi:
Legge 16 byte da /dev/urandom , se esiste.
Chiama openssl_random_pseudo_bytes() , che invoca OpenSSL per ottenere cripto- bit pseudocasuali di qualità .
Chiama mcrypt_create_iv() , con il MCRYPT_DEV_URANDOM flag.
Naturalmente, si possono provare tutte le opzioni disponibili e mescolare tutto ciò che si ottiene. Finché almeno una di queste opzioni funzionerà, starai bene. Ovviamente, se si mescola questo con l'output di api.wordpress.org utilizzando una funzione crittografica, non sarà mai peggio dell'approccio di oggi, e sarà meglio se api.wordpress.org venga mai compromesso.
Quindi, combinando la casualità locale e remota sarebbe stato un approccio migliore. Sfortunatamente, questo richiede un po 'più di lavoro e un po' più di codice. Forse gli sviluppatori hanno preso l'approccio più semplice di interrogare solo api.wordpress.org . Si potrebbe discutere di questa decisione progettuale, ma è possibile capire come questo approccio potrebbe essere stato scelto.
Nel complesso, tuttavia, come sostiene Thomas Pornin, questo non è probabilmente il più grande rischio per la sicurezza di Wordpress. Stiamo parlando di software con una lunga storia di vulnerabilità della sicurezza. Quindi, il rischio incrementale aggiunto da questo aspetto della generazione di numeri casuali potrebbe essere piccolo, rispetto al rischio che stai già prendendo in entrambi i modi.
Vedi anche Generazione sicura di numeri casuali in PHP per ulteriori informazioni sulla generazione casuale di qualità crittografica numeri da PHP e Sarebbe sicuro usare numeri casuali da random.org in una soluzione crittografica? per ulteriori informazioni sul motivo per cui non è una buona idea affidarsi a una fonte remota di numeri casuali per le tue chiavi crittografiche.
Lo stesso motivo per cui molto difficile per generare la propria entropia, in particolare in un ambiente cloud o di hosting condiviso.
Essenzialmente, WordPress sta dicendo che hanno più entropia di te. Probabilmente hanno ragione! Quindi lo generano e lo restituiscono.
È un possibile vettore di attacco. Tuttavia, non penso che sia probabile, perché se è mirato, l'attaccante deve avere il controllo della tua rete già per reindirizzare la chiamata DNS al server corretto. ALLORA, hanno bisogno di falsificare un certificato SSL. Tutto sommato, altamente improbabile.
L'URL è: https://api.wordpress.org/secret-key/1.1/salt/
Quindi usa SSL. Anche se gli hacker sovvertono il DNS per reindirizzare quella chiamata, dovrebbero comunque possedere in qualche modo un certificato server valido contenente il nome api.wordpress.org . In quanto tale, è probabilmente difficile per gli hacker eseguire un server di generazione chiavi falso.
Naturalmente, il server WordPress stesso sarebbe in grado di registrare tutte le chiavi generate e tradire. Nota, tuttavia, che possono già fare ciò inserendo backdoor nel loro software - che usi (potrebbero anche chiamare backdoor "vulnerabilità" e affermare plausibilmente di non averlo fatto apposta). In questo senso, ti stai già fidando delle persone di WordPress; con questa cosa di generazione di chiavi lato server, continui a fidarti di loro. Personalmente non mi preoccuperei troppo di questo (almeno, non tanto quanto il semplice fatto di usare un framework basato su PHP con una lunga storia di sicurezza discutibile).
Come sottolinea @jrg, la generazione sicura di chiavi può essere difficile in alcuni ambienti basati su cloud: un computer ottiene casualità misurando gli eventi fisici dall'hardware; in una macchina virtuale non esiste un vero hardware da misurare. In particolare, alcuni provider di cloud creano istanze di macchine utilizzando le istantanee VM. Tutte le macchine che escono da un'istantanea comune condividono quindi lo stesso stato iniziale, in particolare qualsiasi seme casuale. L'utilizzo della generazione di chiavi sul lato server evita questo problema.
Leggi altre domande sui tag php encryption tls