Como armazenar nome de usuário e senha para API no wordpress opção DB?

18

Atualmente, estou desenvolvendo um plug-in e as chances são de que eu mais provavelmente o disponibilizarei no repositório público de plugins para que outras pessoas possam usá-lo.

O plugin estará usando uma API e para usar esta API você precisa passar um nome de usuário e senha. Então, meu plugin precisa armazenar essas credenciais de login no banco de dados. Eu não quero armazená-los em texto simples, embora a API precise deles em texto simples.

Então, minha pergunta é como armazenar essas informações confidenciais? Hashing está fora, então tem que ser algum tipo de criptografia.

No WordPress, existe uma chave única que pode ser usada para diferir de blog para blog? Quais funções php devo usar para criptografar e descriptografar? Estou procurando funções que provavelmente funcionarão em todas as instalações do WP.

    
por Brady 05.08.2011 / 14:48

3 respostas

4

Embora eu concorde com as respostas anteriores, para responder à pergunta que você fez, o que vem à mente é usar uma dessas constantes para o wp-config.php:

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

Eles são exclusivos das instalações do wordpress - e são as únicas opções de chaves pré-existentes encontradas no wordpress. A alternativa seria adicionar sua própria constante semelhante que é criada ao fazer hash de um deles contra o endereço de e-mail do administrador ou semelhante - e depois armazená-lo em uma opção de configuração oculta - para evitar perder sua chave se alguém acidentalmente modificar as chaves após o plugin está instalado. O perigo é que, se eles não forem exclusivos na instalação inicial, mas o administrador / proprietário do site decidir corrigir a falha após o fato, eles não deverão quebrar acidentalmente a criptografia da senha.

Quanto às funções de criptografia / descriptografia, uma rápida pesquisa no Google retorna a seguinte listagem com o código que parece se ajustar à conta: 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));
}

Veja algumas documentações da criptografia AES usada aqui: enlace

    
por marfarma 13.08.2011 / 02:47
4

Esta é exatamente a circunstância para a qual o OAuth foi projetado.

Na página inicial do OAuth :

  

Para desenvolvedores de provedores de serviços ...

     

Se você está apoiando ...

     
  • aplicativos da web
  •   
  • APIs do lado do servidor
  •   
  • mashups
  •   

Se você estiver armazenando dados protegidos em nome de seus usuários, eles não devem espalhar suas senhas pela Web para obter acesso a elas. Use o OAuth para fornecer aos usuários acesso aos dados deles enquanto protegem as credenciais da conta.

A vantagem do OAuth é que você não precisa armazenar a senha do usuário. Quando eles configuram o plug-in pela primeira vez, eles são solicitados a fazer login com um nome de usuário e uma senha por meio do aplicativo (geralmente uma página hospedada no mesmo servidor da API e carregada em um redirecionamento de página, um thickbox ou um iframe) .

Uma vez que o usuário está logado, o servidor (seu sistema) cria uma chave segura que seu sistema (WordPress) pode usar para fazer interface com a API. Essa chave é exclusiva da conta do usuário e do site - e dá ao aplicativo (no WordPress) permissão para fazer coisas com a API em nome do usuário sem passar suas informações de autenticação a cada vez.

Se você quiser ver um exemplo disso em ação, confira Jetpack .

Quando você ativa o plugin, ele reclama que não está conectado. Quando você "conecta", você insere suas credenciais através do WordPress.com e configura a interação OAuth entre o WordPress e sua API.

Mas você só precisa fazer isso uma vez e seu nome de usuário / senha do WordPress.com nunca é armazenado em seu banco de dados local do WordPress.

    
por EAMann 05.08.2011 / 15:38
0

Esse é um problema importante, pois muitos serviços ainda não suportam o OAuth e o armazenamento de senhas no banco de dados de opções os torna legíveis a todos os plug-ins do Wordpress (veja meu comentário acima).

Esta não é (ainda) uma resposta real para a pergunta, mas também é muito longa para um comentário. Espero iniciar uma discussão com isso, com o objetivo de encontrar a "melhor" solução possível para esse problema "insolúvel".

A ideia básica que me faz pensar que a criptografia de senhas é possível é a seguinte:

Há uma informação secreta que todo usuário tem: sua senha do Wordpress. Deve ser possível armazenar credenciais para serviços de terceiros criptografados com um formulário secreto derivado dessa senha e apenas descriptografá-los quando o usuário estiver logado.

Desta forma, deve ser possível, pelo menos, tornar impossível roubar as senhas de uma cópia dos arquivos do Wordpress e do banco de dados. Ele não pode resolver o problema de outros plug-ins que roubam credenciais, porque cada plug-in pode capturar a senha de texto simples durante o login.

Na verdade, a descriptografia é bastante fácil de fazer: suponha que já tenhamos uma versão criptografada do serviço de terceiros armazenada no banco de dados, podemos conectar-nos ao 'authenticate' filtre ou substituindo a função wp_authenticate() , gere um arquivo salgado Hash da senha de usuário em texto simples (por meio de wp_hash_password() ), armazene essa senha com hash como uma chave de criptografia em algum lugar privada até que o usuário efetue logout (use o gancho 'wp_logout' para excluir a chave) e use-o sempre que precisar a senha de terceiros para descriptografar o valor criptografado no banco de dados.

Embora eu tenha a impressão de que seria possível fazer isso funcionar, existem vários problemas não resolvidos:

  1. Como fazer a criptografia? Potencialmente, é possível armazenar a senha em texto simples até que o usuário efetue logout e login novamente e faça a criptografia durante 'authenticate' . O usuário pode ser solicitado a efetuar login para manter o período até que isso aconteça em pouco tempo.
  2. Onde armazenar a chave e como excluí-la durante o logout? Eu entendi corretamente que 'authenticate' é executado apenas quando o usuário realmente faz o login?
  3. Caso haja agora uma maneira de armazenar a senha com hash, talvez seja possível derivar uma chave do cookie de sessão?
  4. Quem deve lidar com alterações de senha? Parece que é possível catch tais alterações de senha e a senha de terceiros teria que ser novamente criptografada com a chave derivada da nova senha.
  5. Existe uma maneira de fornecer suporte a vários usuários? O ideal seria que um usuário administrador fosse capaz de definir senhas de terceiros nas configurações que poderiam ser processadas por usuários menos privilegiados para interagir com serviços de terceiros, de preferência até mesmo sem divulgar essas senhas a eles. Para isso, o usuário administrador precisaria gerar chaves para todos os usuários que esses outros usuários só podem gerar para si mesmos. Isso é de alguma forma possível?
por cgogolin 05.09.2018 / 10:50