Pois é, hoje estou usando MD5 e acho inseguro, mesmo somente o
admin da base LDAP tendo acesso aos atributos de senha.
Isso depende muito da sua definição de "seguro". :-)
Bom, caso for uma senha fraca, por sorte eu posso decifrar com
uma comparação por dicionário.
Eu sei que pode ser um pouco de viajem da minha parte, mas eu
estou tentando achar algo realmente seguro para armazenar as senhas,
estou dando uma estudada nessa parte de criptografia.
Eu nunca tinha tentado descriptografar uma senha MD5, mas, para
minha surpresa, eu consegui... :-(
Essa eu *realmente* gostaria de saber como foi feito.
MD5 é hash, isso quer dizer que ele foi desenhado pra não
ter retorno, ou seja, é *muito* difícil obter a palavra por trás
do hash, a menos que você esteja usando comparação por dicionário
ou brute-force, o que é ligeiramente diferente já que você não
obter a senha a partir do MD5 e sim através de comparações.
Eu viajei legal nisso!! Eu estava usando uma comparação por
dicionário para
descobrir a
senha, eu tinha feito alguns testes com senhas fracas, e depois que
você falou isso, eu testei com uma senha *mais* complexa e
realmente vi
que estava usando um dicionário! Desculpe a minha ignoracia :-(
Eu pensei em usar o HASH {SASL} para autenticar usando o HASH do
Kerberos (atributo k5key), assim sendo, fazendo um mecanismo de proxy
(userPassword --> saslauthd --> Kerberos ->- k5key), eu já fiz isso
funcionar e funcionou muito bem, mas, eu lembrei que tem a senha do
Samba e que não tem como fazer um proxy igual ao userPassword, mas eu
acho que já ajuda UM pouquinho.
Tem sim, tem um overlay no LDAP pra sincronizar a senha
do kerberos e samba.
Na verdade, o Andrew Bartlett fez um patch para o Heimdal
Kerberos usar a senha do Samba (sambaNTPassword e sambaLMPassword)
quando o usuário tiver o objectClass do Samba, assim sendo, não preciso
do overlay. :-)
Esse overlay só vai *sincronizar* as senhas, ele não vai
dizer que o atributo sambaNTPassword e sambaLMPassword deve utilizar o
atributo k5key para a autenticação, diferente do mecanismo de
transporte do userPassword para o saslauthd (userPassword ->
saslauthd).
Eu vou precisar fazer alguns testes de performace sobre esse
transporte, e sniffer para ver como é feito todo esse transporte de
senha.
Transporte é independente do hash usado. Você pode estar
usando o hash ROT13, o ideal é ter criptografia no transporte,
um item não afeta o outro, mas juntos eles aumentam a visão geral
de segurança.
Verdade, eu não tinha me dado conta.
Nesse caso, estou pensando **somente** no algoritmo.
Então a pergunta está mal colocada, os algoritmos de
hash são matemáticos, o MD5 é bem superior ao MD4, há
diferentes aspectos quando se lida com criptografia, pois os
algoritmos tem diferentes propósitos, itens como mecanismo
de transporte e tamanho de chave influenciam de forma direta
nos algoritmos e técnicas usadas para criptografar e/ou fazer
hash dos dados.
Hummm... entendido!
Eu vou fazer alguns testes com o {SHA} e verificar as compatibilidades.
Foi provado que é possível obter dois hashes MD5
iguais a partir de duas fontes diferentes, mas elas são
conjuntos específicos de dados e ainda não tem uso prático.
Por isso, muita gente foi pro SHA1, ainda assim, o espaço
é limitado e, portanto, é *teoricamente* possível encontrar
dois conjuntos diferentes que gerem o mesmo hash (ainda que
isso seja mais difícil), não é a toa que já há implementações
de SHA256 e SHA512, pra tornar as interseções ainda mais
difíceis de serem encontradas.
Muito interresante :-)
Abraço,
Abraços!
|