OAuth nel plugin open source

Quindi in genere è esattamente il tipo di problema che OAuth è stato progettato per evitare, non creare.

Tu, come fornitore di risorse, hai creato un sistema che hai deciso di proteggere con OAuth e un plug-in di WordPress che funge da client per il tuo sistema.

Bob, che ha un sito WordPress e che vorrebbe usare il tuo sistema, installa il plugin nel suo sito WordPress. Quindi, Bob visita il tuo sistema, lo informa che vorrebbe usarlo e richiede l'accesso. Il sistema quindi gli offre un nuovo, unico segreto cliente. Aggiunge il client secret alla configurazione del plugin sul suo sito e ora può connettersi al tuo servizio utilizzando credenziali che sono uniche per lui.

In questo modo, ogni sito che ha installato il plug-in è identificabile in modo univoco e il segreto del client non deve mai essere noto a nessuno al di fuori del singolo sito WordPress che lo possiede.

Anche se il codice non fosse "open source", nascondere le credenziali in esso sarebbe una cattiva idea. L'ingegneria inversa è brava a trovare segreti nascosti nel codice compilato, tuttavia l'astuzia pensava che lo fosse.

Il tuo problema riguarda una macchina che prova a dimostrare la propria identità su un'altra macchina. Chiamiamo la prima macchina il "client". Il cliente dovrà "sapere qualcosa" che lo distingua da qualsiasi altra macchina; quale documentazione Microsoft tende a chiamare "credenziali". Indipendentemente da come lo fai, queste credenziali verranno memorizzate da qualche parte sul client e sono disponibili in modo automatico, perché vuoi che il tuo client sia in grado di operare senza una supervisione umana attiva. Corrispondentemente, se il sistema operativo è ostile o sovvertito, allora hai perso.

Quindi ciò che ti serve è archiviare le credenziali in un file protetto dal sistema operativo (cioè con i diritti di accesso che tengono fuori gli intrusi). Non puoi fare di meglio comunque, almeno non senza lanciare hardware costoso al problema.

Il modo più semplice per ottenere ciò che vuoi è con un token protetto, che sebbene le dichiarazioni di Pornin siano costose, non è necessario, specialmente perché hai un caso d'uso piuttosto limitato. Ad esempio un Yubikey è di circa $ 25. Si potrebbe anche semplicemente utilizzare un Raspberry Pi per tenere le credenziali fuori dal server e configurarlo per eseguire la crittografia su richiesta. La maggior parte degli schemi di crittografia in uso sono protetti contro Chosen Plaintext Attack ( CPA ).