Blog da Softblue


Este artigo foi criado por Andre Milani.
Conheça o currículo completo do instrutor clicando aqui.

Protegendo senhas

Publicado em 03/03/2011 às 17:58:23 horas.

Compartilhe:    

Neste post eu pretendo debater um pouco sobre a proteção no armazenamento de senhas de clientes e usuários de nossos sites em bancos de dados. Por mais que já estejamos carecas de saber que nossos sites devem prevenir ataques de SQL Injection (inserção de códigos SQL em campos de formulários ou parâmetros de request) e de outros tipos, não deixa de ser uma medida de prevenção proteger ainda mais as senhas cadastradas por nossos usuários em nossos sites, uma vez que temos usuários que utilizam uma senha padrão em vários serviços (obviamente não recomendado), e até mesmo para evitar que outra pessoa de posse da senha do usuário em nosso site possa realizar qualquer operação não autorizada pelo titular da conta.

Os códigos apresentados neste artigo são da linguagem SQL e alguns comandos da linguagem PHP, mas podem ser convertidos para a maioria das linguagens de programação. Para exemplificar o conteúdo abordado neste artigo, vamos considerar inicialmente que temos a seguinte tabela em nosso banco de dados:

ID | USUARIO | SENHA
1    André     123456
2    Milani    abcdef

Mesmo supondo que nosso site seja seguro contra SQL Injection, todos que tiverem acesso ao banco de dados poderão ter acesso às senhas dos usuários. Isto inclui pelo menos os administradores do banco, e em alguns casos também os responsáveis pela hospedagem do site, até mesmo desenvolvedores e pessoas com acessos aos arquivos de backup do banco. Um dos métodos mais tradicionais para se proteger a senha dos usuários é por meio da geração de um código-hash.

Gerando um código-hash

Um código hash é o resultado de um algoritmo de criptografia que recebe como parâmetro um dado, que neste caso pode ser a senha do usuário. Algumas funções são conhecidas como one-way (via única), onde a partir do resultado não é possível realizar o caminho inverso e assim descobrir a senha cadastrada ou o dado passado como parâmetro. Alguns exemplos de algoritmos de hash one-way são o MD5 e o SHA1.

O algoritmo MD5 retorna uma string com 32 posições preenchidas com caracteres hexadecimais, que é formada a partir de uma fórmula própria.

echo md5("123456");  // e10adc3949ba59abbe56e057f20f883e
echo md5("abcdef");  // e80b5017098950fc58aad83c8c14978e

Já o algoritmoSHA1 retorna uma string com 40 posições, formada por uma fórmula própria e diferente do MD5.

echo sha1("123456");  // 7c4a8d09ca3762af61e59520943dc26494f8941b
echo sha1("abcdef");  // 1f8ac10f23c5b5bc1167bda84b833e5c057a77d2

Tanto o MD5 quanto o SHA1 retornam sempre o mesmo resultado para o mesmo parâmetro informado. Isto quer dizer que sempre que a função MD5 for chamada para o parâmetro 123456, o resultado será sempre e10adc3949ba59abbe56e057f20f883e. De posse do código-hash da senha do usuário no momento de seu cadastro, basta armazenar no banco o código-hash em questão, transformando nossa tabela USUARIOS fictícia para o seguinte formato:

ID | USUARIO | SENHA
1    André     e10adc3949ba59abbe56e057f20f883e
2    Milani    e80b5017098950fc58aad83c8c14978e

Neste momento, mesmo com acesso (autorizado ou não-autorizado) nesta tabela, a senha dos usuários não fica tão exposta quanto anteriormente, diminuindo muito as chances de alguém que acesse esta tabela possa realizar alguma ação indevida com estes dados.

Autenticando a senha com o código-hash

Como fazer então para, no momento em que um usuário retornar ao site e desejar se autenticar, validar se a senha que ele informou no login é a mesma senha criptografada no banco? É simples: basta novamente gerar o código-hash da senha informada pelo usuário no momento da autenticação e verificar se os códigos hash são idênticos. Por exemplo:

$usuarioLogin = "andre";
$senhaLogin = "123456";
$senhaLoginHash = md5(senhaLogin);

$sql = "SELECT * FROM USUARIOS WHERE USUARIO = '".$usuarioLogin."' AND SENHA = '".$senhaLoginHash."'";

Se a consulta SQL apresentada retornar algum resultado, é porque temos um usuário autenticando-se com sucesso. Caso contrário, ou o usuário ou a senha foram informados de forma incorreta. Observe neste código que foi utilizada a função MD5 para abordar o exemplo. É importante salientar que é a mesma função de criptografia que deve ser utilizada no cadastro do usuário e no momento de autenticação, ou seja, se no cadastro for utilizado a função SHA1 para criptografar a senha, é a função SHA1 que deve ser utilizada no momento da autenticação.

Proteção contra ataques de força-bruta

Você já protegeu as senhas de seus clientes no banco de dados utilizando criptografia, porém o seu sistema ainda pode estar vulnerável contra ataques de força-bruta. Este tipo de ataque consiste em tentar milhares de combinações de senhas para um determinado usuário pré-conhecido. Por exemplo: um usuário mal-intencionado poderia, de posse do nome do usuário andre, criar um script que enviasse milhares de tentativas de senhas (ou de um dicionário de senhas), até obter sucesso (similar ao tipo de ataque que foi usado para descobrir a conta do Barack Obama no Twitter há um tempo atrás). Para evitar este tipo de ataque, basta você criar um contador de tentativas falhas de autenticação em sua tabela USUARIOS, deixando-a da seguinte forma:

ID | USUARIO | SENHA                            | FALHAS
1    André     e10adc3949ba59abbe56e057f20f883e   0
2    Milani    e80b5017098950fc58aad83c8c14978e   0

Bastaria então incrementar o valor do campo FALHAS a cada tentativa inválida que for realizada para o usuário em questão. Uma regra em seu sistema pode definir que, a partir de três tentativas inválidas de autenticação para um usuário, o sistema bloqueie sua conta, não permitindo novas tentativas e solicitando que o usuário entre em contato para desbloquear a sua senha. Outra regra que poderia ser realizada é: ao atingir 3 senhas inválidas, o sistema não permite que o usuário em questão possa realizar novas tentativas de autenticação nos próximos 15 minutos, o que tornaria um ataque força-bruta bastante inviável.

Vale a pena comentar que o contador FALHAS deve ser zerado toda vez que o usuário em questão consiga se autenticar com sucesso, para evitar que, caso ele esqueça a senha de vez em quando, este contador bloqueie sua senha em um momento futuro sem que ele tenha errado a senha três vezes consecutivas.

Comentários

Muito bom e muito útil o post. Obrigado

Enviado em 26/08/2011 às 01:29:49 horas, por Luis Armando


André Milani, Parabéns pelo POST. Galera, os cursos são excelentes, podem fazer sem medo.

Enviado em 24/06/2011 às 01:49:38 horas, por Cosme Trianoki


Samuel: para você por em prática a funcionalidade dos 15 minutos de espera é simples, basta armazenar no banco (para o usuário em questão) a data com horário do momento que a conta é "bloqueada". A partir deste ponto, nas próximas tentativas de autenticação, você verifica se a diferença do horário atual para o horário da última tentativa é superior a 15 minutos. Se for superior, você realiza a tentativa de autenticação. Se não for, indica que está no período de bloqueio, e você desconsidera a tentativa de login.

Enviado em 22/05/2011 às 13:38:07 horas, por André Milani


Nossa muito boa dica... =D

mas, será que você poderia dar o exemplo de como eu colocar esses 15 minutos de espera? estou fazendo um projeto final e seria muito interessante ter isso nele...

Agradeço desde já

Enviado em 21/05/2011 às 17:54:03 horas, por Samuel Correia


Nossa você explica muitooo bem
bom material de ajuda

Enviado em 13/05/2011 às 14:01:38 horas, por Rodrigo


Gostei da explicação! bem objetivo.

Enviado em 29/04/2011 às 17:49:00 horas, por Shirley Ramos


Muito bom

Enviado em 23/04/2011 às 11:25:12 horas, por Charles Mendes


Ótima explicação, clara e direta.
Parabéns

Enviado em 21/03/2011 às 23:49:19 horas, por Eduardo Augusto


Excepcional!! Sem comentários! Parabéns André, Parabéns softblue pelos seus profissionais..!
Se um simples post no blog está assim, imagine como deve ser um curso!!
Pra mim já me convenceu!
Matricula na certa!
Abraços!

Enviado em 17/03/2011 às 18:23:33 horas, por Eduardo Magno


Excelente explicação!

Enviado em 16/03/2011 às 15:12:15 horas, por França de Sousa


Excelente material. Tem me ajudado bastante.

Enviado em 15/03/2011 às 09:23:53 horas, por Cleijonatas dos Santos e Silva


Parabéns pela matéria, ficou ótima. De forma simples e objetiva conseguiu alertar a todos. Espero mais posts.

Enviado em 10/03/2011 às 09:09:26 horas, por Ronnie Alves Pereira

Mailing List

Cadastre o seu e-mail para receber notícias e informações sobre novos cursos, atualizações e outras novidades da Softblue!

Diferenciais

Liberdade total
Estude quando e como quiser. Disponibilidade do conteúdo 24h por dia, 7 dias por semana.
Matrícula não expira
Pagamento único, sem mensalidades, e acesso vitalício a todo o conteúdo, mesmo após a conclusão do curso.
Cursos sempre atualizados
Acesso às atualizações dos cursos de forma automática.
Tire suas dúvidas
Suporte eficiente para esclarecer suas dúvidas no decorrer do curso.
Padrão de qualidade
Atendimento diferenciado e material de alta qualidade, feito por quem entende do assunto.

Certificado

Insira o código do certificado que deseja consultar:

Pagamento





Conheça todas as nossas formas de pagamento.


             Cursos  |   Perguntas  |   Sobre nós  |   Sorteios  |   Blog  |   Política de Privacidade  |   Contato Desde 2003.    
Todos os direitos reservados ®    
CNPJ 06.860.085/0001-64