Por que as senhas devem ser criptografadas se estiverem sendo armazenadas em um banco de dados seguro?

Eu tenho um serviço web. No momento, tenho senhas armazenadas em texto sem formatação em uma tabela MySQL no meu servidor. Sei que essa não é a melhor prática e é por isso que estou trabalhando nela.

Por que as senhas devem ser criptografadas se estiverem sendo armazenadas em um banco de dados seguro? Sei que, se alguém invadir meu banco de dados, obterá a senha de todos. Mas tenho outros problemas se alguém entrar no meu banco de dados, por exemplo, excluir dados.

O cenário em que consigo pensar é que você está hackeado. Você restaura um banco de dados há algumas horas e está tudo bem. No entanto, se suas senhas estiverem em texto sem formatação ... O ladrão tem todas as senhas e você deve redefini-las. Aborrecer seus usuários.

Se as senhas foram criptografadas, você pode restaurar o banco de dados anterior. Este pensamento está correto?

Primeiro, você deve ser mais livre com direitos de acesso somente leitura do que leitura e gravação. Pode ser possível que um hacker tenha acesso aos seus dados, mas não possa editá-los.

Mas, muito mais importante, isso não é sobre você. O fato de você poder ser ferrado se alguém tiver acesso total ao seu banco de dados é irrelevante. Muito mais importantes são os dados do usuário.

Se você recuperar seu banco de dados, o hacker ainda terá acesso à conta do usuário.

E quem sabe o que mais? E se eles usarem a mesma senha no Google? Ou PayPal? E se isso der ao hacker acesso ao nome de solteira da mãe ou aos quatro últimos dígitos do cartão de crédito?

E se isso os colocar em outras contas? Não deixe passar um hacker para passar por um sistema de suporte ao usuário e obter mais informações .

Apenas ... apenas não. Essas são as informações privadas do usuário e você não precisa vê-las. É também a sua reputação. Criptografá-lo.

EDIT: Um comentário extra, para salvar qualquer futuro leitor de ler todas as respostas e comentários ...

Se você quiser criptografar (no sentido mais estrito), precisará usar um par de chaves pública / privada , o que é bom, mas torna a vida um pouco mais difícil para você e seu usuário.

Uma solução mais simples e eficaz é saltar aleatoriamente e hash a senha. Hashing sozinho não é suficiente; se o usuário usar uma senha comum, ela aparecerá em tabelas de hash reverso, que estão prontamente disponíveis com uma simples pesquisa na Internet.

Se você for invadido, poderá restaurar o site a partir de backups e corrigi-lo. Mas o hacker ainda tem senhas para as contas de todos! Existem exemplos documentados do mundo real disso (Sony, Linked-in), em que se as tabelas de senhas tivessem sido corretamente misturadas e salgadas, seria mais fácil proteger e restaurar o sevice rapidamente.

Provavelmente, é uma boa ideia supor que você será invadido e projetar sua estratégia de backup e criptografar quaisquer dados confidenciais com essa suposição em mente. E não é apenas contra hackers que você precisa se proteger. Funcionários insatisfeitos, desonestos ou sem noção podem dar senhas em texto simples.

Sem hash, você terá que desativar o acesso de todos até que eles alterem sua senha (o que, mesmo se possível, será uma enorme dor de cabeça para todos). Se as senhas tivessem sido hash e salgadas, você poderia restaurar o serviço da Web e seria muito mais difícil para um invasor obter acesso às contas das pessoas.

Uma senha salgada e com hash corretamente é basicamente unidirecional. Você não pode adivinhar facilmente a senha da senha com hash. Mesmo você, como o provedor de serviços não será capaz de adivinhar, você só pode redefini-lo.

Além disso, como Elin disse, não tente usar seu próprio hash (ou criptografia). Use uma biblioteca padrão.

Mas tenho outros problemas se alguém entrar no meu banco de dados, ou seja, excluir dados.

Não se trata dos problemas que você tem, mas dos problemas que isso pode causar a todos os outros usuários. Trata-se de remover a tentação (ou pior ainda, a responsabilidade potencial) de as pessoas que trabalham no site abusarem dos dados armazenados lá.

Veja, mesmo que as pessoas devam usar senhas diferentes em sistemas diferentes, a realidade é que não .

... e como é muito fácil usar hash de senhas, você não tem desculpas para não seguir as práticas recomendadas do setor.

Ataques visíveis, como a exclusão de dados, geralmente são coisas de amadores e são as menores preocupações. Uma das primeiras coisas que um invasor experiente fará é tentar obter acesso legítimo; portanto, mesmo se você corrigir a vulnerabilidade original que ele usou, ele ainda poderá entrar. Ele fará todo o possível para evitar chamar a atenção para si mesmo até que realiza o que ele deseja. Ao deixar as senhas unidas, você potencialmente facilitou muito o trabalho dele. Você também dificultou a detecção e o isolamento de seu futuro comportamento malicioso.

Além disso, nem todos os compromissos oferecem acesso total ao shell. E se a vulnerabilidade usada por um invasor for apenas uma injeção SQL somente leitura na userstabela? Deixar senhas unidas apenas lhe dava acesso total.

Além das razões dadas por outras respostas sobre sua responsabilidade de proteger os dados de seus usuários. O que quero dizer é que não são apenas os usuários que têm algo a perder.

Eu tenho que postar uma resposta aqui sobre uma falácia na própria pergunta. Você está perguntando se as senhas devem ser criptografadas. Ninguém criptografa senhas; ninguém, com exceção de serviços e programas como o Firefox Sync e Roboform, cujo único objetivo é criptografar senhas.

Vamos dar uma olhada nas definições:

Na criptografia, a criptografia é o processo de codificação de mensagens (ou informações) de forma que somente as partes autorizadas possam lê-las.

E hash:

Uma função hash é qualquer algoritmo que mapeia dados de comprimento arbitrário para dados de comprimento fixo.

Em outras palavras, a criptografia é uma conversão bidirecional e o hash é uma conversão unidirecional , portanto, a menos que você decifre para visualizá-las mais tarde, isso não é criptografia.

Além disso, não apenas mistura, sal ! Leia esta página inteira antes de fazer o hash de suas senhas.

Quanto aos algoritmos de hash, nos quais o OP está analisando agora, eu sugeriria qualquer uma das variedades SHA-2 de última geração, como SHA-384 ou SHA-512.

E certifique-se de usar rodadas de hash . Não faça hash uma vez, faça hash várias vezes.

Considere ler esta página para proteger mais seu processo de login.

Segundo, seu banco de dados nunca pode ser seguro o suficiente. Sempre haverá brechas na segurança e riscos em constante evolução. Você deve seguir a Lei de Murphy e sempre se preparar para a pior eventualidade.

Os outros pontos destacados pelo pdr são exatamente o que mais eu diria: pessoas que usam a mesma senha para todos os sites, hackers que usam engenharia social para obter mais informações, etc. etc.

Há um princípio importante em jogo aqui. Há apenas uma pessoa que tem alguma empresa que sabe a senha de um usuário. Esse é o usuário. Nem a esposa / marido, o médico ou mesmo o padre.

Definitivamente, não inclui o programador, administrador de banco de dados ou técnico de sistema responsável pelo serviço que está usando. Isso cria um desafio, pois o programador tem a responsabilidade de receber a prova de que o usuário realmente conhece a senha, que é um problema não trivial a ser resolvido de maneira pura.

A solução pura é ter um mecanismo em que o usuário seja desafiado com alguns dados novos e imprevisíveis e, em seguida, retornar uma resposta que seja baseada nesses dados e em sua senha. Uma implementação disso seria pedir ao usuário para assinar digitalmente alguns dados gerados recentemente com sua assinatura digital, e poderíamos provar matematicamente que eles usaram o mesmo par de chaves criptográficas que eles usaram para criar a conta originalmente.

Na prática, as soluções puras exigem infraestrutura e processamento substanciais do lado do cliente e, para muitos sites, isso geralmente não é apropriado para os dados que estão sendo protegidos.

Uma solução mais comum seria:

No ponto em que uma senha é recebida pela primeira vez no aplicativo, a senha é passada para a função hash, juntamente com o valor aleatório de 'salt' do aplicativo na função hash.

A sequência original é substituída na memória e, a partir deste momento, o hash salgado é armazenado no banco de dados ou comparado com o registro do banco de dados.

Os principais aspectos que fornecem segurança aqui são:

1. O conhecimento do hash não fornece autenticação diretamente.
2. O cálculo reverso da senha do hash é impraticável.
3. O uso de tabelas arco-íris (longas listas de senhas e seus hashes calculados) é mais desafiador porque o hash resultante depende do nome de usuário e da senha.

Você precisa "criptografar" (na verdade, "hash", para uma noção adequada de hash)) as senhas como uma segunda camada de defesa : isso visa impedir que um invasor, que teve uma visão apenas de leitura do banco de dados, aumente isso no acesso de leitura e gravação e, precisamente, começam a alterar os dados. As violações parciais somente leitura acontecem no mundo real, por exemplo, através de algum ataque de injeção SQL de uma conta com acesso somente leitura ou recuperando um disco rígido descartado ou uma fita de backup antiga de um dumpster. Escrevi longamente sobre esse assunto lá .

Quanto às formas adequadas de hash de senhas, consulte esta resposta . Isso envolve sais, iterações e, acima de tudo, não inventar seus próprios algoritmos (a criptografia caseira é uma receita certa para o desastre).

Não vou repetir o que outras pessoas disseram, mas supondo que você tenha o PHP 5.3.8 ou melhor, você deve usar o nativo do PHP bcryptpara armazenar suas senhas. Isso está embutido no PHP. Se você possui PHP 5.5, pode usar a melhor constante de senha disponível. Você também pode usar uma biblioteca para fazer com que o 5.3.8 ou melhor se comporte como o 5.5.

Pergunta sobre estouro de pilha Como você usa o bcrypt para hash de senhas no PHP? explica e as outras respostas explicam mais. Por favor, não mexa tentando fazer isso sozinho.

Concordo com a resposta do pdr, pelas razões indicadas nessa resposta.

Eu acrescentaria o seguinte: você deve fazê-lo porque é fácil e geralmente aceito como prática recomendada para qualquer aplicativo. Mais especificamente, as senhas sempre devem ser salgadas e colocadas em hash antes de serem gravadas em qualquer armazenamento persistente. Aqui está uma boa referência sobre a importância de salgar e escolher um bom hash criptográfico (que também fornece código-fonte gratuito em vários idiomas populares): https://crackstation.net/hashing-security.htm

A pequena quantidade de tempo extra de desenvolvimento vale a proteção que ele oferece aos usuários e à sua reputação como desenvolvedor.

O cenário em que consigo pensar é que você está hackeado.

Outro cenário em que você precisa pensar: alguém gastou US $ 100 no seu DBA (ou quem quer que possa executar consultas selecionadas no seu banco de dados), para fornecer as senhas dos usuários. Ou engenheiros sociais, algum estagiário para fazer isso.

Em seguida, eles usam essas senhas para fazer login no Gmail do usuário ... ou no site de comércio ... (porque as pessoas são ... menos que inteligentes, digamos - e usam a mesma senha nos sites).

Em seguida, o usuário irado processa sua empresa por expor sua senha.

NINGUÉM (incluindo as pessoas da sua empresa) deve poder ler a senha em texto sem formatação. Sempre. Não há negócios legítimos ou necessidade técnica para isso.

Por um lado, mesmo os administradores de banco de dados não devem ver as senhas dos usuários. Colocá-los em hash impedirá isso, caso o administrador decida procurar uma senha e fazer login na conta de seus usuários.

Bem, é surpreendente que ninguém tenha mencionado isso ainda, mas e a segurança FÍSICA do seu banco de dados?

Você pode ter a melhor segurança de TI do mundo, mas isso não impede ninguém que possa obter acesso físico à sua mídia de armazenamento. O que acontece quando sua equipe vence o Superbowl hoje à tarde e surge um pequeno tumulto no centro da cidade, onde fica o seu escritório / provedor de hospedagem? (Como Seattle e Denver, duas grandes áreas de TI nos EUA, não considero isso irracional). A multidão invade seu prédio e, enquanto as autoridades estão sobrecarregadas, alguém pega um pouco do seu hardware com um banco de dados que contém senhas em texto não criptografado?

O que acontece quando os federais aparecem e apreendem seu equipamento porque algum executivo de alto nível estava usando sua posição na empresa para executar operações ilegais de ações? Os federais usam essas senhas para investigar seus clientes, embora não tenham feito nada de errado. Então eles percebem que foi VOCÊ que os deixou vulneráveis.

O que acontece quando seu departamento de TI esquece de limpar as unidades RAID antigas que mantinham seu banco de dados quando faz substituições agendadas antes de "distribuir" as unidades antigas para estagiários e, em seguida, seus colegas de quarto descobrem o que foi deixado para trás e descobrem que podem " vendê-lo e nunca o rastrearam até eles?

O que acontece quando seu servidor de banco de dados explode uma placa-mãe, a TI restaura uma imagem no seu novo servidor e a "carcaça" do servidor antigo é lançada na pilha de reciclagem? Essas unidades ainda estão boas e esses dados ainda estão lá.

Qualquer arquiteto decente sabe que a segurança não é algo em que você "se apega" mais tarde com firewalls e políticas de operações. A segurança deve ser uma parte fundamental do design desde o início, e isso significa que as senhas são unidirecionais, NUNCA transmitidas sem criptografia (mesmo dentro de seus próprios datacenters) e nunca podem ser recuperadas. Qualquer coisa que possa ser recuperada pode ser comprometida.

Deixando de lado o caso de seu banco de dados ser invadido: Como cliente, não gostaria que você soubesse minha senha. Sei que você pode facilmente pegar a senha quando ela chega a um pedido, mas tive uma sensação melhor quando você não a tem à disposição para consultar quando quiser.

Se as senhas forem armazenadas em texto sem formatação, isso significa que são conhecidas pelo usuário e por quem quer que tenha acesso a essa tabela. A idéia toda sobre a implementação de usuários e senhas é garantir que uma determinada sessão em seu sistema pertença a essa pessoa, por motivos de privacidade e segurança.

Se um nome de usuário / senha é conhecido por um grupo de pessoas, torna-se inútil identificar uma pessoa de forma inequívoca e isso cria muitos cenários possíveis para roubo de identidade, fraude ...

É por isso que as senhas são armazenadas usando protocolos de criptografia assimétrica, para garantir que você possa validá-las sem poder lê-las.

Eu acho que há uma falha fundamental na questão. O fato é que não existe um "banco de dados seguro". Deve-se considerar que existem falhas em seu sistema em algum lugar que podem permitir que usuários mal-intencionados acessem dados arbitrários em seus servidores. Heartbleed é um excelente exemplo, sendo uma façanha que esteve na natureza por mais de dois anos antes de ser notada pelos pesquisadores. Você pode ter feito tudo o que sabe para proteger os dados, mas não pode responder por todos os outros softwares que você está usando em seus servidores e pelas maneiras complicadas com que eles interagem.

Se alguém se interessar por você, você será hackeado. É importante fazer o possível para evitar ser invadido em primeiro lugar, mas também para atenuar os danos causados ​​quando isso acontece, colocando o maior número possível de obstáculos. Hash suas senhas. Não é tão difícil de configurar, e você está prestando um desserviço a seus usuários por não levar a privacidade deles a sério. É arrogância pensar que você está de alguma forma mais bem protegido contra ataques maliciosos do que empresas como Yahoo , Sony ou Target , que foram hackeadas.