Criptografia de Senhas no Browser

Com java, na hora que o usuário é cadastrado (por ser ambiente corporativo, não é o próprio usuário que se cadastra):
1- Gero senha automática no server mesmo e mando via e-mail para ele. Essa senha TEM que ser trocada no primeiro acesso.
2- Criptografo (com salt e md5 ou sha-256 ou sha-512) e salvo no banco.
3- Gero uma contra senha usando outro método de criptografia, mas com salt e md5 ou sha-256 ou sha-512.

Ou seja, para cada senha, eu tenho 2 colunas com uma senha e uma contra-senha que são geradas de forma diferentes.

Para o usuário fazer o login:
1- Envio a senha normalmente para o servidor como plain text.
2- Criptografo a senha que ele informou, das duas maneiras mencionadas acima.
3- Busco o registro no banco de dados com o mesmo nome de usuário, senha e contra-senha criptografadas.

Para o usuário trocar a senha:
1- Mesmo processo do cadastramento. Mas antes eu verifico a senha antiga dele e vejo se está válida.

Lembrando que, se você quer ter segurança entre o browser e o servidor, o ideal seria você usar HTTPS…

Não é uma falha de segurança. Como dito, a segurança do canal browser servidor é feita via https. Usar javascript no cliente ainda é bem questionavel.

O recomendado é usar no server um algoritmo de hash apropriado (evite md5 e sha) e armazenar o hash com salt da senha.

Rafael Guerreiro:

Com java, na hora que o usuário é cadastrado (por ser ambiente corporativo, não é o próprio usuário que se cadastra):
1- Gero senha automática no server mesmo e mando via e-mail para ele. Essa senha TEM que ser trocada no primeiro acesso.
2- Criptografo (com salt e md5 ou sha-256 ou sha-512) e salvo no banco.
3- Gero uma contra senha usando outro método de criptografia, mas com salt e md5 ou sha-256 ou sha-512.

Ou seja, para cada senha, eu tenho 2 colunas com uma senha e uma contra-senha que são geradas de forma diferentes.

Para o usuário fazer o login:
1- Envio a senha normalmente para o servidor como plain text.
2- Criptografo a senha que ele informou, das duas maneiras mencionadas acima.
3- Busco o registro no banco de dados com o mesmo nome de usuário, senha e contra-senha criptografadas.

Para o usuário trocar a senha:
1- Mesmo processo do cadastramento. Mas antes eu verifico a senha antiga dele e vejo se está válida.

Lembrando que, se você quer ter segurança entre o browser e o servidor, o ideal seria você usar HTTPS…

Muito obrigado pelas explicações Rafael! Muito bom saber como que esses procedimentos estão sendo realizados no mercado. Mais uma vez obrigado.

Não é uma falha de segurança. Como dito, a segurança do canal browser servidor é feita via https. Usar javascript no cliente ainda é bem questionavel.

O recomendado é usar no server um algoritmo de hash apropriado (evite md5 e sha) e armazenar o hash com salt da senha.

AbelBueno, boa noite! A criptografia da senha ainda no browser e o envio da mesma para o server já criptografada não seria uma boa prática, mesmo utilizando uma das formas que você recomendou?

Obrigado pelas explicações amigo!!

Existem mais técnicas para você aplicar o salt.

Dê uma lida: http://blog.caelum.com.br/guardando-senhas-criptografadas-em-java/

Você pode, por exemplo, pegar todos os caracteres nas posições impares e colocar no final da String. Algo assim:
ABCDE -> ACEBD

Você pode, ainda, adicionar um texto, aplicar o embaralhamento, aplicar o digest (SHA-256 ou SHA-512). E ainda repetir esse processo 2 vezes.

Ou seja, você vai adicionar mais texto e embaralhar o próprio hash gerado da primeira vez. Isso já torna essa senha BEM criptografada. É muito complexo e demorado encontrar outra String que colide, dado esse processo todo. Lembrando de ter 2 senhas criptografadas de forma diferentes, e ai você complica BEM mais a vida do meliante…

Um problema muito perigoso em se tratando de segurança geralmente é a falsa sensação de segurança.

Adicionar mais passos nesse processo de proteção, costuma nos dar mais confiança, nos dá a impressão de que o processo ficou mais seguro, mas será que isso sempre é verdade?

Um dos riscos de adicionar mais passos é que você aumenta a chance de implementar um passo errado, no meio de um processo que já é complexo, e acabar criando uma vulnerabilidade quando estava tentando se proteger melhor.

O ideal é seguir as boas práticas recomendadas e não tentar inventar um método próprio de proteção.
Esse artigo aqui explica bem como chegar num bom resultado final passo a passo.

Há algumas iniciativas para nem se armazenar passwords mais. Ou minimizar o uso através de autenticação por outros serviços (email, facebook, etc). No fim das contas, o elo mais fraco ainda é a senha fraca usada pelo usuário e nenhum humano vai conseguir lembrar uma senha forte diferente para cada serviço que acessa. Eles deveriam usar um Password Manager da vida, mas quase ninguém faz isso.

No lance do javascript no client, eu me perguntaria: que tipo de ataque você está evitando quando criptografa a senha no cliente?
O Https vai impedir que alguém “escute” a conversa entre servidor e browser.
Se o ataque estiver direto no client, não vai ser difícil burlar o javascript no próprio browser também.

Vocês criptografam outros campos também?

Recentemente a base do ingressos.com foi invadida. Recebi um falso email com meu dados de lá (nome complete, RG, CPF etc.). Se pelo menos o CPF estivesse criptografado eu não teria me emputecido. Ele é quase uma senha pessoal. Dá pra fazer bastante coisa sabendo apenas o CPF da pessoa.