Melhor maneira de armazenar a senha na base de dados [fechado]
estou a trabalhar num projecto que tem de ter autenticação (nome de utilizador e senha)
Também se liga a uma base de dados, por isso pensei em guardar o nome de utilizador e a senha. No entanto, parece não ser uma boa idéia ter senhas como apenas um campo de texto em uma tabela sentada na base de dados. Estou a usar o C# e a ligar-me a um servidor expresso de 2008. Alguém pode sugerir (Com tantos exemplos quanto possível) qual a melhor maneira de armazenar este tipo de dados ser?P. S estou aberto à ideia de que esta informação não seja armazenada na base de dados se puder ser fornecida uma boa razão
8 answers
Está correcto que guardar a senha num campo de texto simples é uma ideia horrível. No entanto, quanto à localização vai, para a maioria dos casos que você vai encontrar (e eu honestamente não consigo pensar em nenhum contra-exemplos) armazenar a representação de uma senha na base de dados é a coisa apropriada a fazer. Por representação quero dizer que você quer hash a senha usando um sal (que deve ser diferente para cada usuário) e um algoritmo de 1-way seguro e conservar que, deitando fora a senha original. Em seguida, quando você quer verificar uma senha, você hash o valor (usando o mesmo algoritmo de hashing e salt) e compará-lo com o valor hashed na base de dados.
Então, embora seja uma coisa boa você está pensando sobre isso e é uma boa pergunta, esta é realmente uma cópia dessas perguntas (pelo menos):
- como armazenar da melhor forma as informações do utilizador e o login do utilizador e a senha
- melhor práticas de armazenamento de senhas de base de Dados
- Salgando Sua Senha: Melhores Práticas?
- alguma vez é correcto guardar a senha em texto simples numa variável php ou constante php?
Para esclarecer um pouco mais sobre o bit de salga, o perigo com simplesmente hashing uma senha e armazenamento que é que, se um invasor obtém um porão de sua base de dados, eles ainda podem usar o que são conhecidos como tabelas arco-íris para ser capaz de "descriptografar" a senha (em menos aqueles que aparecem na mesa arco-íris). Para contornar isso, os desenvolvedores adicionam um salt para senhas que, quando corretamente feitas, torna os ataques rainbow simplesmente inviáveis de fazer. Lembre-se que um equívoco comum é simplesmente adicionar a mesma cadeia única e longa a todas as senhas; embora isto não seja horrível, é melhor adicionar sais únicos a cada senha. Leia isto para mais informações.
Antecedentes Nunca ... realmente ... preciso de saber a senha do utilizador. Você só quer verificar se um usuário de entrada sabe a senha de uma conta.
Hash It: Guardar as senhas do utilizador escondidas (encriptação de Sentido Único) através de uma função hash forte. Uma busca por" c# criptografar senhas " dá uma carga de exemplos.
Veja o criador de hash do SHA1 'online' para uma ideia do que uma função de hash produz (mas não use o SHA1 como uma função de hash, use algo mais forte, como SHA256).
Agora, uma senha com hash significa que você (e ladrões de banco de dados) não deve ser capaz de reverter essa hash de volta para a senha original.Como usá-lo: Mas como é que eu uso Esta senha amassada guardada na base de dados?
Quando o utilizador se ligar, dar-lhe-ão o nome de utilizador e a senha (no seu texto original) Você só usa o mesmo código de hash para hash que digitou a senha para obter a versão armazenada.
Então ... , compare as duas senhas tracejadas (hash da base de dados para o utilizador e a senha dactilografada & hashed). Você pode dizer se "o que eles digitaram em" correspondeu "o que o Usuário original digitou para sua senha", comparando seus traços.Crédito Extra:
pergunta: Se eu tivesse a tua base de dados, não podia pegar numa bolacha como o John, O Estripador, e começar a fazer hashs até encontrar correspondência com as tuas senhas guardadas? (uma vez que os usuários escolhem palavras curtas, dicionário de qualquer maneira ... deve ser fácil.
Resposta: Sim ... SIM, podem.
Então, devias "saldar" as tuas senhas. Ver o artigo da Wikipédia sobre salComo hash salgado endurecido com chave, usando um algoritmo seguro como o sha-512.
A melhor prática de segurança não é armazenar a senha (nem mesmo encriptada), mas sim armazenar o hash salgado (com um sal único por senha) da senha encriptada.
Assim é (praticamente) impossível recuperar uma senha de texto simples.
Eu recomendaria cuidadosamente ler os artigos o suficiente com as tabelas Rainbow: O que você precisa saber sobre esquemas seguros de Senha [Ligação morta, Copiar no arquivo da Internet] e Como guardar uma senha de forma segura.
Muitos programadores, incluindo eu, acham que entendem a segurança e a agressividade. Infelizmente, a maioria de nós não.Se você usar OpenID então você não acaba armazenando quaisquer credenciais de todo se eu entender a tecnologia corretamente e os usuários podem usar credenciais que eles já têm, evitando a necessidade de criar uma nova identidade que é específica para a sua aplicação.
Pode não ser adequado se o pedido em questão destina-se exclusivamente a uso interno, embora
O RPX oferece uma forma fácil de integrar o suporte OpenID numa aplicação.
Tudo foi construído para este fim, confira asp.net composição
Eu faria MD5 / SHA1 a senha se não precisasses de ser capaz de reverter o hash. Quando os utilizadores se autenticam, você pode simplesmente cifrar a senha dada e compará-la com o hash. Colisões de Hash são quase impossíveis neste caso, a menos que alguém obtém acesso à base de dados e vê um hash que já tem uma colisão para.