Início / dba / Perguntas / 24370
Accepted
32bitfloat
Asked: 2012-09-16 10:35:41 +0800 CST

Como usar a criptografia aes no PostgreSQL?

  • 772

Eu tentei a criptografia aes usando a seguinte declaração:

SELECT encrypt('test', 'key', 'aes');

que funcionou, mas não consigo descriptografar o valor. Inseri-o em um campo do tipo de dados bytea mas não tenho certeza se foi o caminho certo.

SELECT decrypt(pw, 'key', 'aes') FROM table WHERE ID = 1;

me dá o erro

ERRO: função decrypt(bytea, desconhecido, desconhecido) não existe
LINHA 1: SELECT decrypt(pw, 'chave', 'aes') FROM tabela WHERE ID = 7; ^
DICA: Nenhuma função corresponde ao nome e aos tipos de argumento fornecidos. Talvez seja necessário adicionar conversões de tipo explícitas.

Isso realmente significa que encrypt() é uma função existente, mas não decrypt()? De que outra forma eu poderia recuperar valores criptografados com aes?

postgresql functions

2 respostas

  1. Best Answer

    \df *cryptno psql revela os tipos de argumento do pgcrypto encrypte decryptfunções ( assim como os documentos do PgCrypto ):

                                    List of functions
 Schema |      Name       | Result data type |   Argument data types    |  Type  
--------+-----------------+------------------+--------------------------+--------
 ...
 public | decrypt         | bytea            | bytea, bytea, text       | normal
 public | encrypt         | bytea            | bytea, bytea, text       | normal
 ...

    então ambas as funções encrypte decryptesperam que a chave seja bytea. De acordo com a mensagem de erro, "talvez seja necessário adicionar conversões de tipo explícito".

    No entanto, funciona bem aqui na página 9.1, então suspeito que há mais do que você mostrou. Talvez você tenha outra função também nomeada encryptcom três argumentos?

    Veja como funciona em um Pg 9.1 limpo:

    regress=# create table demo(pw bytea);
CREATE TABLE
regress=# insert into demo(pw) values ( encrypt( 'data', 'key', 'aes') );
INSERT 0 1
regress=# select decrypt(pw, 'key', 'aes') FROM demo;
  decrypt   
------------
 \x64617461
(1 row)

regress=# select convert_from(decrypt(pw, 'key', 'aes'), 'utf-8') FROM demo;
 convert_from 
--------------
 data
(1 row)

    Uau! Uau! Risco de exposição chave, extrema cautela do administrador necessária!

    BTW, por favor, pense cuidadosamente se o PgCrypto é realmente a escolha certa. As chaves em suas consultas podem ser reveladas pg_stat_activitye o sistema registra por log_statementmeio de instruções de criptografia que falham com um erro. IMO é frequentemente melhor fazer criptografia no aplicativo .

    Testemunhe esta sessão, com client_min_messagesativado para que você possa ver o que aparece nos logs:

    regress# SET client_min_messages = 'DEBUG'; SET log_statement = 'all'; 
regress=# select decrypt(pw, 'key', 'aes') from demo;
LOG:  statement: select decrypt(pw, 'key', 'aes') from demo;
LOG:  duration: 0.710 ms
  decrypt   
------------
 \x64617461
(1 row)

    Ops, chave possivelmente exposta nos logs se log_min_messagesfor baixa o suficiente. Agora está no armazenamento do servidor, junto com os dados criptografados. Falhou. Mesmo problema log_statementse ocorrer um erro para fazer com que a instrução seja registrada ou possivelmente se auto_explainestiver habilitada.

    A exposição via pg_stat_activitytambém é possível. Abra duas sessões e:

    • S1:BEGIN;
    • S1:LOCK TABLE demo;
    • S2:select decrypt(pw, 'key', 'aes') from demo;
    • S1:select * from pg_stat_activity where current_query ILIKE '%decrypt%' AND procpid <> pg_backend_pid();

    Opa! Lá vai a chave novamente. Ele pode ser reproduzido sem o LOCK TABLEpor um invasor sem privilégios, é apenas mais difícil acertar o tempo. O ataque via pg_stat_activitypode ser evitado revogando o acesso a pg_stat_activityfrom public, mas serve apenas para mostrar que pode não ser melhor enviar sua chave para o banco de dados, a menos que você saiba que seu aplicativo é a única coisa que o acessa. Mesmo assim, não gosto.

    Se forem senhas, você deve armazená-las?

    Além disso, se você estiver armazenando senhas, não as criptografe bidirecionalmente; se possível , as senhas de sal, então, faça um hash e armazene o resultado . Normalmente, você não precisa recuperar o texto não criptografado da senha, apenas confirme se o hash armazenado corresponde à senha que o usuário envia para você fazer login quando é hash com o mesmo sal.

    Se for autenticação, deixe outra pessoa fazer isso por você

    Melhor ainda, não armazene a senha, autentique-se em LDAP, SASL, Active Directory, um provedor OAuth ou OpenID ou algum outro sistema externo que já esteja projetado e funcionando.

    Recursos

    e muito mais.

    • 20

  2. Após instalar a extensão pgcrypto, para criptografar em AES-256 use:

    pgp_sym_encrypt('".$value."', '".$key."', 'compress-algo=1, cipher-algo=aes256')

    tipo de campo de resultado é bytea. Armazenado como está no campo do tipo bytea do PostgreSQL. Para descriptografar o bytea:

    pgp_sym_decrypt(your_table.your_bytea_column , '".$key."', 'compress-algo=1, cipher-algo=aes256')

    também campos bytea podem ser codificados/decodificados de/para base64 com funções de codificação/decodificação;

    encode(your_table.your_bytea_column, 'base64') //result is string
decode(your_table.your_string_column, 'base64') //result is bytea
    • 0

relate perguntas