OAuth en el complemento de código abierto

Por lo general, es exactamente el tipo de problema que OAuth fue diseñado para evitar, no para crear.

Usted, como proveedor de recursos, ha creado un sistema que ha decidido proteger con OAuth y un complemento de WordPress que actúa como un cliente para su sistema.

Bob, que tiene un sitio de WordPress y desea utilizar su sistema, instala el complemento en su sitio de WordPress. Luego, Bob visita su sistema, le informa que le gustaría usarlo y solicita acceso. El sistema entonces le da un secreto de cliente nuevo y único. Agrega el secreto del cliente a la configuración del complemento en su sitio, y ahora puede conectarse a su servicio utilizando credenciales que son únicas para él.

De esta manera, cada sitio que ha instalado el complemento es identificable de manera única, y el secreto del cliente nunca debe ser conocido por nadie más que el único sitio de WordPress que lo posee.

Incluso si el código no fuera "de código abierto", ocultar las credenciales sería una mala idea. La ingeniería inversa es buena para encontrar secretos ocultos en el código compilado, por muy astuto que el desarrollador pensó que era.

Su problema es sobre una máquina que intenta demostrar su identidad a otra máquina. Llamemos a la primera máquina el "cliente". El cliente necesitará "saber algo", lo que lo diferencia de cualquier otra máquina; lo que la documentación de Microsoft tiende a llamar "credenciales". Independientemente de cómo lo haga, estas credenciales se almacenarán en algún lugar del cliente y estarán disponibles de forma automática, ya que desea que su cliente pueda operar sin la supervisión activa de personas. En consecuencia, si el sistema operativo es hostil o subvertido, entonces ha perdido.

Entonces, lo que necesita es almacenar las credenciales en un archivo protegido por el sistema operativo (es decir, con derechos de acceso que impiden la entrada de intrusos). No puedes hacerlo mejor de todos modos, al menos no sin lanzar hardware costoso al problema.

La forma más fácil de lograr lo que desea es con un token seguro, que aunque Pornin afirma que no es caro, especialmente porque tiene un caso de uso bastante limitado. Por ejemplo, un Yubikey cuesta aproximadamente $ 25. También puede usar una Raspberry Pi para mantener las credenciales fuera del servidor y configurarla para que realice el cifrado a pedido. La mayoría de los esquemas de encriptación en uso son seguros contra el ataque de texto simple ( CPA ).