Hardening
| Deixe um comentário e acompanhe a discussão assinando a feed deste ou de todos os posts e comentários. |
Conversando com o Anchises e o Augusto ontém tocamos no assunto GINA (Graphical Indentification and Authentication DLL) a dll que é responsável pelas telas de logon do Windows.
Viajando um pouco eu pensei em fortalecer um pouco o sistema de autenticação do windows customizando a MsGina.dll, evitando ataques de keyloger e dificultando a quebra de senhas da SAM (Security Account Manager).
Como? substituindo as senhas digitadas pelo usuário por senhas mais fortes geradas por um algoritmo. Dessa forma o usuário continuaria criando as senhas fracas como nome, data de aniverssário sem enfraquecer o sistema de autenticação da maquina.
Ex.:
Portanto apesar de a senha memorizada e usada pelo usuário ser fraca a senha que vai estar na SAM vai ser sempre a senha forte gerada pelo algoritmo. Logicamente esse algoritmo deve ser implementado em todos os processos de criação, alteração de senha e autenticação.
Com essa implementação dificultariamos muito a quebra de senhas da SAM e eliminariamos o problema dos keyloger, o keyloger irá capturar a senha "joão" digitada pelo usuário, essa senha não é a senha gravada na SAM e só será validada quando digitada na GINA adaptada, portanto usuários externos que capturarem a senha não poderão fazer nada com ela.
Vou pensar melhor nessa solução e fazer um protótipo, breve colocarei algo aqui.
Gustavo Araujo Bittencourt on September 25th, 2005
Oi Wagner,
Pelo que eu entendi, seria adicionar um hash intermediário entre a entrada da senha no teclado e o algorítmo de hash que armazena ou compara as senhas no SAM. Entendi corretamente?
Algumas questões em função deste meu entendimento:
- Dependendo do algorítmo utilizado no hash intermediário, pode-se reduzir o keyspace, o que facilitaria ataques por força bruta.
- Como ficaria a autenticação entre um sistema que utilizasse este recurso e um que não utilizasse?
- Essa solução protegeria apenas senhas locais e de domínio, as senhas de internetbank continuam não seriam afetadas.
- Me parece ser segurança por obscurantismo, pois para ser eficiente o atacante não pode ter consciência desta camada extra, muito menos do algorítimo hash utilizado nesta camada intermediária.
[]s
Wagner Elias, CBCP on September 26th, 2005
Oi Gustavo,
realmente é uma camada a mais, uma espécie de hash intermediário mesmo.
A questão do algorítmo é uma coisa q ainda estou desenvolvendo, mais acredito que não iria reduzir o keyspace, pensei em algo utilizando salt no hash e uma chave que ficaria protegida por permissões de arquivo, etc…(o ponto fraco ainda continua sendo a chave como em qualquer projeto), a chave seria gerada por movimento do mouse, aumentando a entropia da chave, pensei em algo parecido com o que Keypass usa para gerar a chave.
Sim essa implementação “protegeria” somente o windows ou aplicações integradas via ADSI.
Acredito que não seja segurança por obscuridade, seria uma camada a mais.
Mais é um experimento, qualquer sugestão, crítica é benvinda.
Victor Pereira on September 27th, 2005
No windows VISTA, não será mais possivel se alterar a msgina.dll.
Mesmo assim, o dificil seria tratar o legado.
Victor Pereira on September 27th, 2005
De qualquer forma, melhor do que se usar arquivo com permissao, seria usar a DPAPI http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/windataprotection-dpapi.asp
wagnereliassp on September 27th, 2005
Realmente Victor o legado seria um problema. Ainda não cheguei a estudar as características do Windows Vista, mais sem dúvida a parte de autenticação dele deve ter melhorado, visto a facilidade que existe em “burlar” o sistemas windows atuais (xp, windows 2000, 2003).
O Dpapi é uma opção interessante, mais ele iria alterar o sistema deautenticação local ou é um sistema para integrar sistema de autenticação de aplicações? Vou dar uma estudada no material.
Abs.
Victor Pereira on September 28th, 2005
Olá Wagner,
A parte de autenticação do VISTA mudou, eu li a muito tempo atras num newsgroup da ms que ficará parecido com PAM (Pluggable Authentication Module).
Na verdade a DPAPI ela veio pra tratar o famoso problema: “No final a chave fica em claro na memoria”. Ela serve somente para encrypt e decrypt, o armazenamento continua sendo em reg + permissao restritiva ou LSA (SAM).