password encriptadas em C# e php

candycane

Power Member
Boa tarde comunidade,
eu tenho que fazer 2 sistemas de login, um em C# e outro em php... A minha duvidada é como se faz para ter as passwords encriptadas nessas duas linguagens.

Alguém pode dar-me uma luzinha? :)
 
Não se diz encriptar, mas sim cifrar, e não é isso que o algoritmo MD5 faz.

MD5 dá-te uma hash, ou seja funciona apenas num sentido, ie: sabes que o md5 de abc é 19s38Jsk54dakd8aj mas não consegues a partir de 19s38Jsk54dakd8aj chegar a abc (na verdade este "não consegues" não é tão linear assim, mas vamos partir do princípio que isto é impossível).

Para que é que isto serve? Imagina que tens uma tabela onde queres guardar as passwords de x utilizadores. Obviamente, guardá-las em plain text seria uma irresponsabilidade. Qualquer pessoa com acesso à tabela conseguiria ver as passwords dessas pessoas. Assim guardam-se estas hashes. Quando o utilizador fôr a fazer login, comparas o md5 da password que ele inseriu com a hash guardada.
 
O método ideal de guardar passwords é colocá-las de uma forma que não possam ser desencriptadas.
Uma forma comum antigamente de fazer as coisas era:
- encriptar a password e guardar na BD
- o utilizador escreve a password para fazer login
- desencripta-se da BD e compara-se a que o utilizador introduziu com a desencriptada

No entanto, a grande falha deste sistema é que no caso da base de dados ser comprometida, as passwords dos utilizadores, sendo desencriptáveis, também são comprometidas (e basta pensar que uma boa percentagem das pessoas usa a mesma password em todo o lado para perceber os problemas que isso acarreta).

Um algoritmo de hashing é seguro para os utilizadores na medida em que é "one-sided", isto é, uma vez aplicado sobre uma qualquer string, não dá para pegar nela e voltar atrás. O algoritmo mais usado é o MD5 - Message Digest 5.

O que o hostmake disse foi para gravares o hash MD5 da password na BD (considerando que as passwords são gravadas numa Base de Dados), e depois comparares o MD5 da password introduzida com o que está na BD.
Um método seria
PHP:
if(md5($_POST["password"])==$password_da_bd)

No entanto, para tornar esse sistema ainda mais seguro, o ideal seria o MD5 ser feito do lado do cliente por JavaScript (mas sem te fiares completamente neste sistema), pois assim torna-se ainda mais complicado a password ser interceptada por eavesdropping.

Continua a ser possível descobrir a password, mas só através de um pesado e moroso processo - bruteforce (ir experimentando sequências de caracteres até que alguma delas dê a hash)

A segurança é sempre uma coisa complicada. Mas acho que o pessoal é unânime no que toca a usar o MD5 :P
(isso também te explica porque é que o "Esqueci-me da password" permite criar uma nova, mas não permite enviar ao utilizador a password dele para o mail :) )

edit - o stradale antecipou-se :P
 
O md5 é um bom metodo para ter as passwords encriptadas, pois é o mais usado e sendo assim, ao mudar de sistema, é relativamente fácil transferir todos os utilizadores para esse novo sistema com as suas passwords, pelo que para passwords, o md5 é o mais aconselhado.
 
O md5 é um bom metodo para ter as passwords encriptadas, pois é o mais usado e sendo assim, ao mudar de sistema, é relativamente fácil transferir todos os utilizadores para esse novo sistema com as suas passwords, pelo que para passwords, o md5 é o mais aconselhado.
Mudar de sistema? Como assim?
 
O melhor ainda será usares o MD5 com um SALT....
Isto é, acrescentares à hash da password uma variável. Isto torna mais dificil o ataque de força bruta. Pois, neste momento, já existem pela Web várias repositorios de palavras e a respectiva hash em MD5/SHA. Basta, por exemplo, procurares no Google por uma hash e são retornados logo uns quantos resultados e até com sorte a respectiva palavra em plain/text.

Ao adicionares uma variavel tua quando crias a hash tornas o ataque de força bruta mais dificil porque o atacante para além de ter que descobrir a variavel para criar o "dicionario" ainda tem q gerar um novo, e não usar que já tenha.


PHP:
<?php

/* $password contains the password */


$salt = 'SALTINHO';
$password = $_POST['passwd'];
$password_hash = md5($salt . md5($password . $salt));

/* Store password hash */

?>
 
Só adicional ao tal problema com o eavesdropping:

Quando alguém faz login, manda a password por HTTP POST. Se for desencriptada, pode ser apanhada no meio da comunicação, e o captor fica com a password que pode usar onde quiser. Se for em md5 (com ou sem $salt), o captor fica com a encriptação da password. Não vai saber qual é, mas pode usar a hash para fazer login no teu site.

O meu método teórico seria encriptar a password no cliente (ficando a hash igual à que está na BD) e encriptar de novo esse hash com uma variável aleatória passada no form (portanto, vinda do servidor). Pode ser um timestamp, um ID, uma hash, qualquer coisa. Funcionaria como "salt" aleatório. Enviava-se para o servidor o resultado dessas duas hashes, e a variável aleatória recebida. O server iria buscar o hash da pass à BD, e faria de novo hash com a variável aleatória, para validar a password.
É essa a minha ideia :sad:
 
Seria precisamente isso que eu faria :D Assim, torna-se impossível reutilizar a informação interceptada.
O problema depois está nos clientes sem javascript/com o javascript desactivado. Esses enviariam os campos em plain text, pelo que o servidor também teria de estar prevenido quanto a isso.
 
Seria precisamente isso que eu faria :D Assim, torna-se impossível reutilizar a informação interceptada.
O problema depois está nos clientes sem javascript/com o javascript desactivado. Esses enviariam os campos em plain text, pelo que o servidor também teria de estar prevenido quanto a isso.
Só adicional ao tal problema com o eavesdropping:

Quando alguém faz login, manda a password por HTTP POST. Se for desencriptada, pode ser apanhada no meio da comunicação, e o captor fica com a password que pode usar onde quiser. Se for em md5 (com ou sem $salt), o captor fica com a encriptação da password. Não vai saber qual é, mas pode usar a hash para fazer login no teu site.

O meu método teórico seria encriptar a password no cliente (ficando a hash igual à que está na BD) e encriptar de novo esse hash com uma variável aleatória passada no form (portanto, vinda do servidor). Pode ser um timestamp, um ID, uma hash, qualquer coisa. Funcionaria como "salt" aleatório. Enviava-se para o servidor o resultado dessas duas hashes, e a variável aleatória recebida. O server iria buscar o hash da pass à BD, e faria de novo hash com a variável aleatória, para validar a password.
É essa a minha ideia :sad:

Olá, só quero deixar uma advertência quanto à tua sugestão. O método que descreveste, como certamente saberás, chama-se Autenticação com Desafio-Resposta. A ideia consiste em criar uma hash da password do utilizador, juntamente com um valor aleatório (tipicamente chamado nonce) ou uma marca temporal (timestamp); com isto podes mitigar ataques passivos (password sniffing; brute-force da hash, etc.)

Agora este método tem dois problemas, que têm que ser tomados em conta:

  1. Tanto o cliente, como o servidor, têm que conhecer previamente a password (ou a hash da password, neste caso). Se reparares, na tua descrição, o que estás basicamente a propor é que a password seja a hash da password do utilizador. Deste modo, basta um atacante ter acesso à base de dados, para se poder autenticar como um utilizador, visto que nunca precisa saber a password original em si, mas apenas a hash. Uma solução para o problema das bases de dados, embora hardcore, mas que permite a utilização de passwords simples, é, por exemplo, utilizar o Augmented-EKE.
  2. Não protege contra ataques activos, como man-in-the-middle e reflection attacks. A não ser que autentiques também o servidor, podendo ser utilizado a mesmo segredo partilhado entre ambos (exemplos: Kerberos; MS-CHAP-V2); ou utilizes uma ligação cifrada, onde autenticaste previamente a identidade do servidor, por exemplo, através de um certificado X.509.
Concluindo, a segurança não é fácil de implementar, existem muitos exemplos, em todo o lado, onde a segurança foi efectivamente mal desenhada e implementada, sendo um dos mais mediáticos o caso do WEP; o próprio WPA tem alguns problemas.

99.9% das vezes é preferível utilizarmos mecanismos, protocolos e software previamente desenvolvidos, que já foram estudados, cripto-analisados e, se ainda estão a funcionar hoje, é porque oferecem, até à data, algumas garantias mínimas quanto à sua segurança. Por exemplo, se não estou em erro, o google utiliza simplesmente HTTPS na fase de autenticação; resolve, assim montes de problemas à partida...

Não quero dar a ideia que estou aqui a criticar :| Só quero dar a conhecer alguns dos problemas que, mais cedo ou mais, se podem vir a deparar...

Cumps,
JP
 
Back
Topo