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

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

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

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

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

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

Apenas ... apenas não. Essa é a informação privada do seu usuário e você não precisa ser capaz de vê-lo. Também é sua reputação. Criptografe.

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

Se você for criptografar (no sentido mais estrito), será necessário 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 é random-salt 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 hackeado, 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 sobre isso acontecendo (Sony, Linked-in), onde se as tabelas de senhas foram corretamente divididas e salgadas, protegendo e restaurando sevice rapidamente teria sido muito mais fácil.

Provavelmente, é uma boa ideia assumir que você será invadido, projetar sua estratégia de backup e criptografar quaisquer dados confidenciais com essa suposição em mente. E não são apenas hackers que você precisa proteger. Empregados descontentes, desonestos ou simplesmente ignorantes poderiam dar senhas de texto simples.

Sem hash você terá que desabilitar o acesso de todos até que eles mudem sua senha (o que, mesmo que seja possível, será uma grande dor de cabeça para todos). Se as senhas fossem criptografadas 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 com hash e salgada é basicamente unidirecional. Você não pode adivinhar facilmente a senha da senha com hash. Mesmo você, como o provedor de serviços não conseguirá adivinhá-lo, você só poderá redefini-lo.

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

But I have other problems if someone gets in my database, i.e. deleting data.

Não é sobre os problemas que você tem, é sobre os problemas que isso pode causar a todos os outros usuários. Trata-se de eliminar a tentação (ou, ainda pior, responsabilidade potencial) de pessoas que trabalham no site para abusar de dados armazenados lá.

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

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

Os ataques perceptíveis, como a exclusão de dados, costumam ser o assunto de amadores e são a menor das suas preocupações. Uma das primeiras coisas que um invasor experiente fará é tentar obter acesso legítimo, por isso, 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 ele realiza o que ele deseja. Ao deixar as senhas inalteradas, você apenas tornou o trabalho dele muito mais fácil. Você também tornou mais difícil detectar e isolar seu futuro comportamento malicioso.

Além disso, nem todas as concessões oferecem acesso total ao shell. E se a vulnerabilidade usada por um atacante for apenas uma injeção SQL somente leitura na tabela users ? Deixar as senhas inalteradas deu-lhe praticamente acesso total.

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

Eu tenho que postar uma resposta aqui sobre uma falácia na questão em si. 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 o Roboform, cujo único propósito é criptografar senhas.

Vamos dar uma olhada nas definições:

In cryptography, encryption is the process of encoding messages (or information) in such a way that only authorized parties can read it.

E hashing:

A hash function is any algorithm that maps data of arbitrary length to data of a fixed length.

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

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

Quanto aos algoritmos de hashing, que o OP agora está analisando, sugiro qualquer um dos vários tipos de SHA-2, como SHA-384 ou SHA-512.

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

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

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

A outros pontos que o pdr faz são exatamente o que mais eu diria: as pessoas que usam a mesma senha para cada site, hackers usando engenharia social para obter mais informações etc. etc.

Há um princípio importante em jogo aqui. Há apenas uma pessoa que tenha algum negócio sabendo a senha de um usuário. Esse é o usuário. Não sua esposa / marido, seu médico ou até mesmo seu 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 provar que o usuário realmente conhece a senha, o que é um problema não trivial de se resolver de uma maneira pura.

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

Na prática, as soluções puras requerem uma infra-estrutura e processamento substancial 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 de hash, juntamente com o valor 'salt' aleatório do aplicativo na função hash.

A string original é então sobrescrita na memória e, a partir daí, 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 inverso da senha do hash é impraticável.
3. O uso de tabelas de arco-íris (longas listas de senhas e seus hashes calculados) se torna mais desafiador porque o hash resultante é dependente do nome de usuário e senha.

Você precisa "criptografar" (na verdade, "hash", para uma noção adequada de hashing) as senhas como uma segunda camada de defesa : isso é feito para evitar que um invasor receba uma vislumbre somente leitura do banco de dados, de escalonar isso para acesso de leitura / gravação e, precisamente, começar a alterar os dados. Violações parciais somente leitura acontecem no mundo real, por exemplo, através de algum ataque de injeção de 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 este assunto lá .

Quanto às formas adequadas de hash de senhas, consulte esta resposta . Isso envolve sais, iterações e, acima de tudo, não inventando 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 PHP 5.3.8 ou melhor, você deve estar usando o PHP nativo bcrypt para armazenar suas senhas. Isso é construído no PHP. Se você tiver o PHP 5.5, poderá usar a melhor constante de senha disponível. Você também pode usar uma biblioteca para fazer o 5.3.8 ou se comportar melhor como 5.5.

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

Concordo com a resposta de pdr, pelas razões expostas nessa resposta.

Gostaria de acrescentar o seguinte: você deve fazê-lo porque é fácil fazer e geralmente aceito como prática recomendada para qualquer aplicativo. Mais especificamente, as senhas sempre devem ser salgadas e hashed 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): link

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

The scenario I can think of is that you are hacked.

Outro cenário em que você precisa pensar: alguém colocou seu DBA (ou quem mais pode executar consultas selecionadas no seu banco de dados) $ 100, para dar a ele as senhas dos usuários. Ou engenheiros sociais, algum interno 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 inteligentes do que podemos dizer - e usam a mesma senha em todos os sites).

Então o usuário irado processa sua empresa por expor sua senha.

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

Por um lado, até administradores de banco de dados não devem ver as senhas dos usuários. Hashing impedirá isso caso o administrador decida procurar uma senha e faça o login na conta de seus usuários.

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

Você pode ter a melhor segurança de TI do mundo configurada, mas isso não impede que qualquer pessoa possa obter acesso físico à sua mídia de armazenamento. O que acontece quando sua equipe vence o Superbowl esta tarde, e uma pequena revolta irrompe na área central da cidade onde seu escritório / provedor de hospedagem está? (Dado que é Seattle vs. Denver, duas grandes áreas de TI nos EUA, não acho que isso seja irracional). A multidão entra no seu prédio e, enquanto as autoridades estão sobrecarregadas, alguém pega um pouco do seu hardware com um DB que contém senhas de texto puro?

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 com ações ilegais? Então, 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 o departamento de TI se esquece de limpar as antigas unidades RAID que mantinham seu banco de dados quando fazem substituições agendadas antes de "entregar" as unidades antigas aos estagiários e, em seguida, encontrar o que sobrou e descobrir eles podem "vendê-lo" e nunca rastreá-los?

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

Qualquer arquiteto decente sabe que a segurança não é algo que você "usa" posteriormente com firewalls e políticas de operações. A segurança tem que 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 recuperáveis. Qualquer coisa que possa ser recuperada pode ser comprometida.

Deixando de lado o caso do seu banco de dados sendo invadido: Como cliente, não quero que você saiba minha senha. Eu sei que você pode facilmente pegar a senha quando ela vem em um pedido, mas eu tenho uma sensação melhor quando você não tem à sua disposição para consultar sempre que quiser.

Se as senhas forem armazenadas em texto simples, isso significa que elas são conhecidas pelo usuário e por quem tiver acesso a essa tabela. Toda a ideia sobre a implementação de usuários e senhas é garantir que uma determinada sessão em seu sistema pertença a uma pessoa, por motivos de privacidade e segurança.

Se um nome de usuário / senha for conhecido por um grupo de pessoas, torna-se inútil inequivocamente identificar uma pessoa, 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étricos, para garantir que você possa validá-las sem ser capaz de 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 exploração que esteve em estado selvagem 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 contabilizar todos os outros softwares que está usando nos seus servidores e as formas complicadas que eles interagem.

Se alguém se interessar por você, você será atacado. É importante fazer o seu melhor para evitar ser hackeado em primeiro lugar, mas também para atenuar o dano que é causado quando isso acontece, colocando tantos obstáculos no lugar quanto possível. Hash suas senhas. Não é tão difícil de configurar, e você está fazendo um desserviço aos seus usuários por não levar a sério sua privacidade. É arrogante pensar que você está de alguma forma melhor protegido contra ataques maliciosos do que empresas como Yahoo ou Sony , ou Alvo , todos os quais foram hackeados.