Protegendo a senha do MySQL ao desenvolver em Python?

Resposta curta

Você não pode.

Se a senha estiver armazenada no artefato enviado ao usuário final, você deve considerá-lo comprometido! Mesmo que o artefato seja um binário compilado, sempre há maneiras (mais ou menos complicadas) de obter a senha.

A única maneira de proteger seus recursos é expor apenas uma API limitada ao usuário final. Crie uma API programática (REST, WS+SOAP, RMI, JavaEE+Servlets, ...) ou exponha apenas certas funcionalidades em seu banco de dados via SPROCs (veja abaixo).

Algumas coisas primeiro...

A questão aqui não deve ser como esconder a senha, mas como proteger o banco de dados. Lembre-se de que apenas senhas geralmente são uma proteção muito fraca e não devem ser consideradas o único mecanismo de proteção do banco de dados. Você está usando SSL? Não? Bem, então mesmo se você consegue esconder a senha no código do aplicativo, ainda é fácil farejá-la na rede!

Você tem várias opções. Todos com diferentes graus de segurança:

"Função do aplicativo"

Crie um usuário de banco de dados para o aplicativo. Aplique autorização para esta função. Uma configuração muito comum é permitir apenas operações CRUD.

Prós

muito fácil de configurar
Evita DROP consultas (por exemplo, em injeções de SQL?)

Contras

Todo mundo vendo a senha tem acesso a todos os dados do banco de dados. Mesmo que esses dados estejam normalmente ocultos no aplicativo.
Se a senha estiver comprometida, o usuário poderá executar UPDATE e DELETE consultas sem critérios (ou seja:excluir/atualizar uma tabela inteira de uma vez).

Auth&auth atômica

Crie um usuário de banco de dados por aplicativo/usuário final. Isso permite que você defina direitos de acesso atômico mesmo em uma base por coluna. Por exemplo:O usuário X só pode selecionar colunas far e baz da tabela foo. E nada mais. Mas o usuário Y pode SELECT tudo, mas sem atualizações, enquanto o usuário Z tem acesso CRUD completo (selecionar, inserir, atualizar, excluir).

Alguns bancos de dados permitem que você reutilize as credenciais no nível do sistema operacional. Isso torna a autenticação ao usuário transparente (só precisa fazer login na estação de trabalho, essa identidade é então encaminhada ao banco de dados). Isso funciona mais facilmente em um MS-stack completo (OS =Windows, Auth =ActiveDirectory, DB =MSSQL), mas - até onde sei - também é possível alcançar em outros bancos de dados.

Prós

Bastante fácil de configurar.
Esquema de autorização muito atômico

Contras

Pode ser tedioso configurar todos os direitos de acesso no banco de dados.
Usuários com UPDATE e DELETE direitos ainda podem acidentalmente (ou intencionalmente?) excluir/atualizar sem critério. Você corre o risco de perder todos os dados em uma tabela.

Procedimentos armazenados com autenticação e autenticação atômica

Escreva não Consultas SQL em seu aplicativo. Execute tudo através de SPROCs. Em seguida, crie contas de banco de dados para cada usuário e atribua privilégios aos SPROCs somente .

Prós

Mecanismo de proteção mais eficaz.
SPROCs podem forçar os usuários a passar critérios para cada consulta (incluindo DELETE e UPDATE )

Contras

não tenho certeza se isso funciona com o MySQL (meu conhecimento nessa área é esquisito).
ciclo de desenvolvimento complexo:tudo o que você deseja fazer deve primeiro ser definido em um SPROC.

Considerações finais

Você nunca deve permitir tarefas administrativas de banco de dados para o aplicativo. Na maioria das vezes, as únicas operações que um aplicativo precisa são SELECT , INSERT , DELETE e UPDATE . Se você seguir esta diretriz, dificilmente haverá risco de os usuários descobrirem a senha. Exceto os pontos mencionados acima.

Em qualquer caso, mantenha backups. Suponho que você queira projetar seu banco de dados contra exclusões ou atualizações acidentais. Mas acidentes acontecem... tenha isso em mente;)