Come archiviare nome utente e password nell'API nel DB di opzioni wordpress?

Attualmente sto sviluppando un plugin e le probabilità sono che molto probabilmente lo rilascerò sul repository di plugin pubblico in modo che altri possano usarlo.

Il plugin utilizzerà un'API e per utilizzare questa API è necessario passare un nome utente e una password. Quindi il mio plugin deve archiviare queste credenziali di accesso nel database. Non voglio archiviarli in testo normale sebbene l'API ne abbia bisogno in testo normale.

Quindi la mia domanda è: come posso conservare queste informazioni sensibili? L'hashing è fuori, quindi deve essere una sorta di crittografia.

In WordPress esiste un tasto univoco che può essere utilizzato in modo diverso da blog a blog? Quali funzioni php dovrei usare per crittografare e decrittografare? Sto cercando funzioni che molto probabilmente funzioneranno su tutte le installazioni di WP.

Mentre sono d'accordo con le risposte precedenti, per rispondere alla domanda che hai effettivamente posto, quello che mi viene in mente è usare una di queste costanti per wp-config.php:

define ('AUTH_KEY', 'redacted');
define ('SECURE_AUTH_KEY', 'redacted');
define ('LOGGED_IN_KEY', 'redacted');
define ('NONCE_KEY', 'redacted');

Sono pensati per essere unici tra le installazioni di wordpress e riguardano le uniche opzioni per le chiavi preesistenti che si trovano in wordpress. Alternativo sarebbe aggiungere la tua costante simile che viene creata eseguendo l'hashing di una di esse sull'indirizzo e-mail dell'amministratore o simili - e quindi memorizzandola in un'opzione di impostazione nascosta - per proteggerti dalla perdita della chiave se qualcuno modifica accidentalmente le chiavi dopo il tuo il plugin è installato. Il pericolo è che se non sono stati resi univoci durante l'installazione iniziale, ma l'amministratore / il proprietario del sito decidono di correggere l'errore dopo il fatto, non dovrebbero rompere accidentalmente la crittografia della password.

Per quanto riguarda le funzioni di crittografia / decrittografia: una rapida ricerca su Google restituisce il seguente elenco con il codice che sembra adattarsi al conto: http://maxvergelli.wordpress.com/2010/02/17/easy-to-use-and-strong- funzioni php cifratura-decifratura-/

funzione crittografare ($ input_string, $ chiave) {
    $ iv_size = mcrypt_get_iv_size (MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
    $ iv = mcrypt_create_iv ($ iv_size, MCRYPT_RAND);
    $ h_key = hash ('sha256', $ key, TRUE);
    return base64_encode (mcrypt_encrypt (MCRYPT_RIJNDAEL_256, $ h_key, $ input_string, MCRYPT_MODE_ECB, $ iv));
}

funzione decrypt ($ crittografato_input_string, $ chiave) {
    $ iv_size = mcrypt_get_iv_size (MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
    $ iv = mcrypt_create_iv ($ iv_size, MCRYPT_RAND);
    $ h_key = hash ('sha256', $ key, TRUE);
    return trim (mcrypt_decrypt (MCRYPT_RIJNDAEL_256, $ h_key, base64_decode ($crypted_input_string), MCRYPT_MODE_ECB, $ iv));
}

Ecco un po 'di documentazione sulla crittografia AES utilizzata qui: http://www.chilkatsoft.com/p/php_aes.asp

Questa è esattamente la circostanza per cui OAuth è stato progettato.

Dalla homepage di OAuth :

Per gli sviluppatori di provider di servizi ...

Se stai supportando ...

• applicazioni web
• API lato server
• mashup

Se stai memorizzando dati protetti per conto dei tuoi utenti, non dovrebbero diffondere le loro password sul Web per accedervi. Utilizza OAuth per consentire ai tuoi utenti di accedere ai propri dati proteggendo al contempo le credenziali dell'account.

Il vantaggio di OAuth è che non è necessario archiviare la password dell'utente. Quando configurano il plug-in per la prima volta, viene chiesto di accedere con un nome utente e una password tramite l'applicazione (in genere una pagina ospitata sullo stesso server dell'API e caricata in un reindirizzamento della pagina, in una thickbox o in un iframe) .

Una volta effettuato l'accesso, il server (il tuo sistema) crea una chiave sicura che il suo sistema (WordPress) può utilizzare per interfacciarsi con l'API. Questa chiave è unica per l'account utente e il sito e fornisce all'applicazione (su WordPress) il permesso di fare cose con l'API per conto dell'utente senza passare ogni volta le informazioni di autenticazione.

Se vuoi vedere un esempio di questo in azione, dai un'occhiata a Jetpack .

Quando si attiva il plug-in, si lamenta che non è collegato. Quando lo "colleghi", inserisci le tue credenziali tramite WordPress.com e imposta l'interazione OAuth tra WordPress e la loro API.

Ma devi farlo solo una volta e il tuo nome utente / password WordPress.com non vengono mai memorizzati nel tuo database WordPress locale.

Questo è un problema importante, poiché molti servizi non supportano ancora OAuth e l'archiviazione delle password nel database delle opzioni li rende leggibili per ogni singolo plugin di Wordpress (vedi il mio commento sopra).

Questa non è (ancora) una vera risposta alla domanda, ma anche troppo a lungo per un commento. Spero di innescare una discussione con questo, con l'obiettivo di trovare la "migliore" soluzione possibile a questo problema "irrisolvibile".

L'idea di base che mi fa pensare che sia possibile crittografare le password è la seguente:

Esistono informazioni segrete di ogni utente: la password di Wordpress. Dovrebbe essere possibile archiviare le credenziali nei servizi di terze parti crittografate con un modulo derivato segreto che password e decrittografarle solo quando l'utente è connesso.

In questo modo dovrebbe essere possibile almeno rendere impossibile il furto delle password da una copia dei file e del database di Wordpress. Non può risolvere il problema degli altri plugin che rubano le credenziali, poiché ogni plugin può acquisire la password in chiaro durante l'accesso.

In realtà la decrittazione è piuttosto semplice: supponiamo di avere già una versione crittografata del servizio di terze parti memorizzato nel database, possiamo agganciarci al 'authenticate'filtro o sovrascrivendo la wp_authenticate()funzione, generare un hash salato della password dell'utente in testo semplice (da mezzo di wp_hash_password()), archiviare quella password con hash come chiave di crittografia in un luogo privato fino a quando l'utente non si disconnette (utilizzare il 'wp_logout'gancio per eliminare la chiave) e utilizzarla ogni volta che è necessaria la password di terze parti per decrittografare il valore crittografato nel database.

Mentre ho la sensazione che dovrebbe essere possibile farlo funzionare, ci sono comunque diversi problemi irrisolti:

1. Come si fa la crittografia? Potenzialmente si potrebbe archiviare la password in testo normale fino a quando l'utente non si disconnette e si riconnette ed esegue la crittografia durante 'authenticate'. All'utente potrebbe essere richiesto di accedere per mantenere il periodo fino a quando ciò non si verifica breve.
2. Dove conservare la chiave e come eliminarla durante la disconnessione? Capisco correttamente che 'authenticate'viene eseguito solo quando l'utente accede effettivamente?
3. Nel caso in cui ora sia possibile archiviare la password con hash, forse si può invece ricavare una chiave dal cookie di sessione?
4. Chi gestire le modifiche della password? Sembra che sia possibile rilevare tali modifiche alla password e la password di terze parti dovrebbe quindi essere crittografata nuovamente con la chiave derivata dalla nuova password.
5. C'è un modo per fornire supporto multiutente? Idealmente si vorrebbe che un utente amministratore fosse in grado di impostare password di terze parti nelle impostazioni che possono quindi essere citate in giudizio dagli utenti meno privilegiati per interagire con servizi di terze parti, idealmente anche senza rivelare loro quelle password. Per questo, l'utente amministratore dovrebbe essere in grado di generare una chiave per tutti gli utenti che tali altri utenti possono generare solo per se stessi. È in qualche modo possibile?