Não existem recursos MySQL integrados para lidar com configurações sofisticadas de chaves criptografadas. Você precisará implementar a maior parte da lógica de criptografia em seu próprio código PHP e / ou do lado do navegador (JavaScript?).
Mas suas preocupações declaradas são um pouco peculiares: Parece que suas únicas preocupações reais são uma injeção de SQL ou força bruta (adivinhação de senha, eu suponho) ataque de uma estação de trabalho de desktop / laptop de cliente remoto. Isso me faz suspeitar que você já tenha planejado algumas outras medidas de segurança não mencionadas e analisou as possíveis vias de comprometimento.
-
Por um lado, estou assumindo que você tem regras de firewall protegendo o host MySQL / PHP contra qualquer tipo de acesso de IPs de clientes remotos não aprovados. Se estiver correto, faz sentido que você esteja preocupado apenas com os ataques das estações de trabalho dos usuários comprometidos.
-
Além disso, estou supondo que você entenda que, se um invasor no host do cliente remoto puder escalar para root / Admin privs ou comprometer diretamente a própria conta do usuário real, os dados desse cliente não terão proteção zero, independentemente da criptografia. ou quaisquer outras salvaguardas. (O invasor pode ler as chaves de onde quer que elas sejam salvas no disco ou espioná-las quando o usuário real as digita no logon, e as chaves levam aos dados.)
A partir dessas duas suposições, faz sentido concluir que as únicas duas ameaças relevantes são A) adivinhação de senha de força bruta e B) Tentativas de injeção de SQL:
- Se o invasor não obtiver a chave do usuário real ou se quiser acessar mais do que apenas os dados do usuário real, ele poderá tentar criar creds de logon forçados para o usuário real ou para outra conta. (Teoricamente, você poderia bloquear cada conta para um IP de cliente remoto específico, o que ajudaria a compartimentar os riscos também.)
- Se o invasor obtiver uma chave válida para o usuário real, ele terá uma avenida além da tela de logon (que, presumivelmente, é simples o suficiente para ser segura), para o ponto fraco do código do aplicativo com potencial de bugs. Uma injeção de SQL bem-sucedida do contexto do usuário real também poderia fornecer acesso a outros dados de clientes.
Agora, vamos falar sobre como a criptografia do lado do servidor se aplica a essas situações:
- A criptografia do lado do servidor definitivamente ajuda contra a ameaça de injeção de SQL. Se os valores de linha forem criptografados nas tabelas de banco de dados, o invasor só poderá ver texto codificado sem sentido dos dados pertencentes a outras contas. A ameaça está contida, compartimentada.
- Brute forçando a adivinhação de senha, no entanto, não é realmente mais difícil para um invasor que enfrenta a criptografia do lado do servidor. Independentemente de as chaves dos usuários serem armazenadas no servidor ou geradas no local a partir da senha, a única coisa que importa é se você tem a senha correta. O servidor decide permitir que você use a chave armazenada válida porque verifica se sua senha está correta ou calcula a chave válida porque sua senha é a entrada correta para gerar essa chave.
A criptografia do lado do cliente, por outro lado, torna os ataques de senha de força bruta irrelevantes. Você não pode forçar brutalmente uma chave construída adequadamente. A criptografia do lado do cliente mantém basicamente o mesmo nível de proteção contra injeção SQL do que a criptografia do lado do servidor também. O cliente pode passar a chave para o servidor no logon, mantendo uma cópia na memória até que a sessão termine, o que coloca a carga do processador de criptografia no servidor. Ou, o cliente pode manipular a criptografia / descriptografia por si só, no navegador. Há altos e baixos nas duas técnicas:
- Passar sua chave para o servidor é muito mais fácil de codificar e gerenciar, e geralmente muito mais rápido por conta de um código de criptografia mais otimizado (C provavelmente compilado).
- Uma abordagem pura do lado do cliente oferece segurança extra, porque, mesmo que um invasor crie raiz no servidor, ele ainda não poderá ler os dados criptografados e nunca conseguirá lê-lo. O único vetor de ataque possível é comprometer a estação de trabalho do cliente remoto.
Finalmente, vou observar que existem algumas desvantagens operacionais enormes na criptografia de dados no banco de dados. Como as representações de dados criptografados são essencialmente padrões aleatórios, os recursos básicos do banco de dados, como indexação, junções, etc., não funcionarão. O cliente assume uma enorme carga lógica e pode perder muitos benefícios que os recursos do banco de dados normalmente trazem.