Primeiro de tudo, isso NÃO melhora a segurança do seu aplicativo (supondo que seja um aplicativo da web).
Use SSL (ou, na verdade, TLS, que é comumente chamado de SSL), não é muito caro (avalie o tempo que você está usando para encontrar maneiras de contorná-lo e multiplicá-lo pelo salário mínimo, a compra de um certificado ganha quase sempre).
O porquê disso é simples. O TLS resolve um problema (quando usado com certificados comprados, não autoassinado) que é bastante grande em criptografia: como sei se o servidor com o qual estou falando é o servidor com o qual acho que estou falando? Os certificados TLS são uma maneira de dizer: "Eu, a autoridade de certificação, confiável pelo seu navegador, certifica que o site em [url] possui essa chave pública, com uma chave privada correspondente, que (chave privada) somente o servidor conhece, procure Eu assinei minha assinatura em todo o documento, se alguém a alterou, você pode ver ".
Sem o TLS, qualquer criptografia se torna inútil, porque se eu me sentar ao seu lado em uma cafeteria, posso fazer seu laptop / smartphone pensar que sou o servidor e o MiTM (Man in the Middle) você. Com o TLS, seu laptop / smartphone gritará "CONEXÃO NÃO CONFIÁVEL", porque não tenho um certificado assinado pela autoridade de certificação que corresponda ao seu site. (Criptografia x autenticação).
Isenção de responsabilidade: os usuários tendem a clicar com o botão direito através destes avisos: "Conexão não confiável? O quê? Eu só quero minhas fotos de gatinhos! Adicionar exceção Clique em Confirmar Clique YAY! Gatinhos!"
No entanto, se você realmente não deseja comprar um certificado, ainda implemente o hash javascript do lado do cliente (e use a biblioteca standford (SJCL) para isso, NUNCA IMPLEMENTAR CRIPTO A MESMO ).
Por quê? Reutilização de senha! Posso roubar o cookie da sua sessão (o que me permite fingir ao seu servidor que sou você) sem HTTPS facilmente (consulte firesheep). No entanto, se você adicionar um javascript à sua página de login que, antes de enviar, faça hash na sua senha (use o SHA256, ou melhor ainda, use o SHA256, envie uma chave pública que você gerou e depois criptografe o hash da senha com isso, você não poderá usar salt) com isso) e envia a senha com hash / criptografada para o servidor. REHASH o hash no seu servidor com um salt e compare com o que está armazenado no seu banco de dados (armazene a senha assim:
(SHA256(SHA256(password)+salt))
(salve o salt como texto simples também no banco de dados)). E envie sua senha assim:
RSA_With_Public_Key(SHA256(password))
e verifique sua senha assim:
if SHA256(RSA_With_Private_Key(SHA256(sent_password))+salt_for_username) == stored_pass: login = ok
Porque, se alguém estiver farejando seu cliente, ele poderá fazer login como seu cliente (sequestro de sessão), mas NUNCA verá a senha de texto sem formatação (a menos que altere seu javascript, no entanto, um hacker da starbucks provavelmente não saberá como se interessar .) Assim, eles terão acesso ao seu aplicativo da web, mas não ao e-mail / facebook / etc. (para os quais seus usuários provavelmente usarão a mesma senha). (O endereço de e-mail será o nome de login ou será encontrado em seu perfil / configurações no seu aplicativo da web).