¿Cómo almacenar el nombre de usuario y la contraseña en la API en la opción DB de wordpress?

18

Actualmente estoy desarrollando un complemento y es probable que lo lance en el repositorio público de complementos para que otros puedan usarlo.

El complemento utilizará una API y para utilizar esta API debe pasar un nombre de usuario y contraseña. Así que mi complemento necesita almacenar estas credenciales de inicio de sesión en la base de datos. No quiero almacenarlos en texto sin formato, aunque la API los necesita en texto sin formato.

Entonces, mi pregunta es ¿cómo almaceno estos datos confidenciales? El hash está fuera, por lo que tiene que ser algún tipo de cifrado.

En WordPress, ¿hay una clave única que se pueda usar y que diferirá de un blog a otro? ¿Qué funciones php debo usar para cifrar y descifrar? Estoy buscando funciones que probablemente funcionarán en todas las instalaciones de WP.

    
pregunta Brady 05.08.2011 - 14:48

3 respuestas

4

Si bien estoy de acuerdo con las respuestas anteriores, para responder la pregunta que realmente hiciste, lo que me viene a la mente es usar una de estas constantes para wp-config.php:

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

Están destinados a ser únicos en todas las instalaciones de wordpress, y son casi las únicas opciones para las claves preexistentes que se encuentran en wordpress. Alternativo sería agregar su propia constante similar que se construye mediante el hash de uno de ellos contra la dirección de correo electrónico del administrador o similar, y luego almacenarlo en una opción de configuración oculta, para protegerse contra la pérdida de su clave si alguien modifica accidentalmente las claves después de su El plugin está instalado. El peligro es que, si no se hicieron únicos en la instalación inicial, pero el propietario del administrador / sitio decide corregir el error después del hecho, no deberían romper accidentalmente el cifrado de su contraseña.

En cuanto a las funciones de cifrado / descifrado, una búsqueda rápida en Google devuelve la siguiente lista con el código que parece corresponder a la factura: enlace

function encrypt($input_string, $key){
    $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));
}

function decrypt($encrypted_input_string, $key){
    $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($encrypted_input_string), MCRYPT_MODE_ECB, $iv));
}

Aquí hay algo de documentación sobre el cifrado AES utilizado aquí: enlace

    
respondido por el marfarma 13.08.2011 - 02:47
4

Esta es exactamente la circunstancia para la que OAuth fue diseñado.

Desde la página de inicio de OAuth :

  

Para desarrolladores de proveedores de servicios ...

     

Si estás apoyando ...

     
  • aplicaciones web
  •   
  • API del lado del servidor
  •   
  • mashups
  •   

Si está almacenando datos protegidos en nombre de sus usuarios, no deben distribuir sus contraseñas en la web para acceder a ellos. Use OAuth para dar a sus usuarios acceso a sus datos mientras protege las credenciales de sus cuentas.

La ventaja de OAuth es que no es necesario almacenar la contraseña del usuario. Cuando configuran el complemento por primera vez, se les pide que inicien sesión con un nombre de usuario y contraseña a través de la aplicación (generalmente una página alojada en el mismo servidor que la API y cargada en un redireccionamiento de página, un thickbox o un iframe) .

Una vez que el usuario ha iniciado sesión, el servidor (su sistema) crea una clave segura que su sistema (WordPress) puede usar para interactuar con la API. Esta clave es exclusiva de la cuenta de usuario y del sitio, y otorga a la aplicación (en WordPress) permiso para hacer cosas con la API en nombre del usuario sin pasar su información de autenticación cada vez.

Si desea ver un ejemplo de esto en acción, consulte Jetpack .

Cuando activa el complemento, se queja de que no está conectado. Cuando lo "conecta", ingresa sus credenciales a través de WordPress.com y configura la interacción OAuth entre WordPress y su API.

Pero solo tiene que hacer esto una vez y su nombre de usuario / contraseña de WordPress.com nunca se almacenará en su base de datos de WordPress local.

    
respondido por el EAMann 05.08.2011 - 15:38
0

Este es un tema importante, ya que muchos servicios aún no son compatibles con OAuth y el almacenamiento de contraseñas en la base de datos de opciones las hace legibles para todos y cada uno de los complementos de Wordpress (vea mi comentario más arriba).

Esto no es (todavía) una respuesta real a la pregunta, pero también es demasiado largo para un comentario. Espero iniciar una discusión con esto, con el objetivo de encontrar la "mejor" solución posible para este problema "sin solución".

La idea básica que me hace pensar que es posible cifrar contraseñas es la siguiente:

Hay una pieza de información secreta que cada usuario tiene: su contraseña de Wordpress. Debería ser posible almacenar credenciales para servicios de terceros encriptados con una forma secreta derivada de esa contraseña y descifrarlas solo cuando el usuario está conectado.

De esta manera debería ser posible, al menos, hacer que sea imposible robar las contraseñas de una copia de los archivos de Wordpress y la base de datos. No puede resolver el problema de otros complementos que roban credenciales, ya que cada complemento puede capturar la contraseña de texto sin formato durante el inicio de sesión.

El descifrado en realidad es bastante fácil de hacer: supongamos que ya tenemos una versión encriptada del servicio de terceros almacenada en la base de datos, podemos enlazar a 'authenticate' o sobrescribiendo la función wp_authenticate() , genere un salado hash de la contraseña del usuario de texto sin formato (a través de wp_hash_password() ), almacene esa contraseña de hash como una clave de cifrado en algún lugar privado hasta que el usuario cierre sesión (use el enlace 'wp_logout' para eliminar la clave) y úselo cada vez que lo necesitemos la contraseña de terceros para descifrar el valor cifrado en la base de datos.

Aunque tengo la sensación de que debería ser posible hacer que esto funcione, hay varios problemas sin resolver:

  1. ¿Cómo hacer el cifrado? Potencialmente, se podría almacenar la contraseña de texto sin formato hasta que el usuario cierre la sesión y vuelva a iniciarla y realice el cifrado durante 'authenticate' . Se le puede pedir al usuario que inicie sesión para mantener el período hasta que esto ocurra corto.
  2. ¿Dónde almacenar la clave y cómo eliminarla durante el cierre de sesión? ¿Entiendo correctamente que 'authenticate' solo se ejecuta cuando el usuario realmente inicia sesión?
  3. En el caso de que ahora haya una manera de almacenar la contraseña con hash, ¿quizás se pueda obtener una clave de la cookie de sesión?
  4. ¿Quién manejará los cambios de contraseña? Parece que es posible catch dichos cambios de contraseña, y la contraseña de terceros tendría que volver a cifrarse con la clave derivada de la nueva contraseña.
  5. ¿Hay una manera de proporcionar soporte multiusuario? Lo ideal sería que uno quisiera que un usuario administrador pudiera establecer contraseñas de terceros en las configuraciones que luego pueden ser demandadas por usuarios menos privilegiados para interactuar con servicios de terceros, idealmente incluso sin revelarles esas contraseñas. Para esto, el usuario administrador deberá poder generar claves para todos los usuarios que esos otros usuarios solo pueden generar por sí mismos. ¿Es eso de alguna manera posible?
respondido por el cgogolin 05.09.2018 - 10:50

Lea otras preguntas en las etiquetas