Como garantir aos usuários que site e senhas são seguros [fechado]

Em sites confiáveis, sempre vejo declarações como "Todos os dados são criptografados" ou "Todas as senhas são criptografadas usando a criptografia de 128 bits" e etc.

No meu site, armazenarei todas as senhas de usuário em um banco de dados depois de usar o hash SHA-512 (provavelmente) com um sal aleatório. Desejo adicionar um snipet que garanta aos usuários que suas senhas são seguras para que não sejam impedidos de usar meu site, pois exige uma senha. Quero que os usuários se sintam seguros, mas não acho que todos saibam o que é hash.

MINHA PERGUNTA: Posso enviar uma mensagem dizendo "Todas as senhas são criptografadas e seguras", pois não acho que o usuário médio saiba qual é a diferença entre hash e criptografia e provavelmente se sentirá seguro apenas por ver a palavra de conforto "criptografia"? Ou há uma mensagem alternativa que devo fornecer?

Em uma nota lateral, eu sou novo em criptografia e hash de senha e estava pensando se isso seria seguro o suficiente por enquanto, ao iniciar meu site. Não quero dizer aos usuários que é seguro, se não for. Qualquer informação seria muito apreciada. Obrigado.

1. Usuários não se importam.

   O único momento em que eles se importam é quando alguém retira o dinheiro da conta bancária e parece que ele tem um link que, alguns dias antes, alguém obteve acesso total ao seu banco de dados.

2. Em quase todos os casos que vi essas mensagens, elas eram enganosas. O mais hilário foi em um site com rótulos "estilo militar seguro" em todas as páginas. Houve um alerta informando que o certificado HTTP é inválido. Houve uma injeção de SQL no formulário de logon. Algumas semanas depois, o site foi invadido e desapareceu para sempre.

   Paro de contar o número de sites que afirmam manter as informações seguras, enquanto possui um formulário "Recuperar minha senha", que na verdade envia a senha original por e-mail.

   É como aqueles rótulos "W3C XHTML válido". Por que eles geralmente são colocados em sites em que até uma página inicial contém pelo menos dezenas de erros e códigos semelhantes <DIV COLOR='red'>?

Se você ainda deseja tranquilizar os usuários, pode colocar algo como:

Suas senhas são mantidas em segurança. Lembre-se de que não podemos ver sua senha e nunca enviaremos um email solicitando que você forneça uma.

Mas, francamente, o formulário "Redefinir minha senha" substituindo o "Esqueci minha senha; envie-a por e-mail" é muito mais tranquilizador do que qualquer palavra.

Dicas dos diferentes comentários:

• Não reinvente a roda: use o OpenID. Dessa forma, você nem armazena os hashes.

  Fonte: comentário de Jan Hudec .

• Como você é estudante, abra seu projeto de código-fonte. Como sua preocupação é: "Não quero que os usuários pensem que suas senhas não são seguras porque alguma criança na escola a projetou". , não há nada mais tranquilizador do que poder verificar, lendo o código-fonte, se ele foi escrito por um desenvolvedor habilidoso que se preocupa com a segurança.

  Fonte: comentário de Jan Doggen .

Não armazene senhas em primeiro lugar! Siga o exemplo do Stack Exchange e permita que os usuários efetuem login com sua identidade em outro site que forneça autenticação via OpenID . As implementações estão disponíveis gratuitamente para as estruturas da Web mais comuns.

Ou possivelmente qualquer outro protocolo. Se for um projeto interno para alguma instituição (como sugere o seu comentário na outra resposta), quase certamente já existe um LDAP, Kerberos (o Windows Active Directory também é baseado nesses dois; o apache suporta autenticação HTTP contra eles) ou alguns serviço para login no computador. Basta conectar-se a isso.

Isso evita que você armazenar informações sensíveis (você provavelmente ainda tem de permissões de loja, mas eles não são que crítico) e os usuários de ter que lembrar ainda outro nome de usuário e senha, de modo geral win-win.

Dizendo:

"Isso é seguro."

é um julgamento pessoal que você faz sobre certos fatos ou processos tecnológicos, e esse julgamento é limitado pelo que você mesmo sabe sobre segurança na época. Mas você pode garantir, sem dúvida, que sua criptografia, método de armazenamento, etc. suportará qualquer tipo de ataque, mesmo aqueles que você não conhece ou ainda não conhece?

Significado: Esta declaração corre o risco de estar desatualizada, talvez mesmo sem você estar ciente disso.

Por isso, tendem a concordar com o comentário acima de @JoachimSauer: Apenas descreva o que você faz, como salva as informações do usuário e diz aos usuários como isso deve tornar seu serviço seguro. Então deixe que os usuários julguem por si mesmos.

Realmente depende do contexto do seu site específico.

Por exemplo, se este for um site de consumidor, é provável que a maioria deles se preocupe apenas com suas senhas (talvez), informações financeiras / de saúde (dependendo) e suas informações privadas, como fotos (hahaha, sim, certo ...) .

Se esse for um aplicativo comercial, o nível de segurança de todo o site é relevante, não apenas senhas. Da mesma forma, depende de quem são seus usuários-alvo - altamente técnicos / não tão técnicos, etc.

Todo esse contexto define muito o que você deve comunicar e que nível de garantia é necessário.

Por exemplo, para consumidores não técnicos, é suficiente ter alguns comentários genéricos e simples, como:

Este site foi construído usando técnicas de segurança de ponta. Sua senha é sempre criptografada e nunca enviaremos suas fotos para a NSA.

(E, como outros já disseram, é melhor você nem ter senhas, use algum padrão como OpenId ou OAuth.)

Para empresas altamente técnicas, convém ter uma página completa de detalhes técnicos e de procedimentos, como:

Implementamos um SDL (ciclo de vida de desenvolvimento seguro) completo em todo o processo de desenvolvimento e implantação.
...
Nossa arquitetura de segurança é ... Isso oferece os benefícios de ...
Garantimos a codificação segura, como ... por ... Realizamos esses e esses testes.
Nossa criptografia inclui esses algoritmos ... e ... Estamos em conformidade com qualquer regulamentação do setor que você precisa e certificada para ...
Nossa segurança é verificada por esse consultor independente.
...
Para obter mais detalhes e revisar nossas políticas ou organizar uma auditoria independente, discuta com o departamento de marketing.

Claro, você não quer estar dando muito informações muito detalhadas, deve ser mais sobre o processo do que as próprias senhas ... E é claro que deve ir sem dizer que a realidade deve realmente cumprir com o que você escreve lá , qualquer que seja o contexto com o qual você esteja lidando.

Como uma das respostas mencionadas, a maioria dos usuários não se importa, não entenderia o que você disser e ainda assim se inscreveria, mesmo se você disser que envia dados do usuário à NSA.
Isto não é para eles.
Eles ficariam felizes em não ter senhas, deixe-me escolher meu nome de usuário na lista e me conectar automaticamente.

Obviamente, isso é para a pequena porcentagem que importa - você deve permitir que os usuários inteligentes façam o que é certo, dar a eles as informações de que precisam e conceder a eles a educação que possam solicitar.
Caso contrário, quando isso der errado, os outros 98% acordarão de repente e ficarão com raiva.
("Claro, eu sabia que não precisava de uma senha para ver minhas fotos, mas não achei que mais alguém pudesse vê-las !!")

Se você deseja que seu sistema seja seguro, a força do algoritmo de senha não faz sentido - a maioria dos hackers pode decifrar senhas em pouco tempo, especialmente se a senha escolhida for pequena ou composta de palavras genéricas que o hacker já "decifrou e armazenou" "usiong rainbow tables e similares. Leia o artigo da ArsTechnica sobre quebra de senha para obter muitas informações.

O que você precisa fazer é garantir aos usuários que os bandidos não conseguem acessar seus hashes em primeiro lugar. Uma empresa preocupada com a segurança em que trabalhei tinha um sistema da web de três camadas em que os servidores da web não estavam fisicamente conectados aos servidores de banco de dados. Quando meu chefe quis colocar seu site e ter acesso direto ao banco de dados (código mal projetado, disse nuff), ele foi informado de que não podia possuí-lo, e quando ele pressionou ... foi informado que não havia fios entre eles. . Ele teve que arquitetá-lo para transmitir todas as solicitações de dados por meio de um serviço de camada intermediária. E esses serviços não foram apenas protegidos, mas expuseram uma superfície mínima ao ataque e foram bloqueados. E o DB nunca expôs nenhuma de suas tabelas para leitura, apenas procedimentos armazenados que, por sua vez, foram bloqueados para que apenas o serviço relevante tivesse acesso.

Não foi tão ruim de codificar quanto você poderia pensar: depois de conhecer a arquitetura e a separação de cada camada, era muito fácil codificá-las.

Você pode desenvolver o site mais seguro do planeta e ter uma experiência muito ruim do usuário. Os usuários assumirão que seu site é inseguro.

Você pode criar o site menos seguro do planeta e ter uma experiência incrível do usuário. Os usuários assumirão que seu site é seguro. Pelo menos até aparecer no noticiário da noite.