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).

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.

Mesmo assim, o dificil seria tratar o legado.

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.

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