Executando verificação de segurança...
26
moyseys
1 min de leitura ·

Pitch: Criei um Gerenciador de Senhas para uso pessoal

A partir de uma necessidade pessoal, criei e hospedei um gerenciador de senhas.

listagem

Durante o desenvolvimento, decidi usar o projeto como estudo, e por causa disto tem uma arquitetura relativamente robusta para somente 1 usuário usar. Optei por usar uma arquitetura de microserviços (tem só 2 serviços no momento, mas ainda virão mais...).

Com esse projeto aprendi várias coisas valiosas relacionadas à segurança, principalmente o conceito de Zero Knowledge, que é de maneira simplória, um conceito que diz que o servidor não pode ter informação suficiente para saber o "segredo" do usuário, que nesse caso, são as senhas.

Ainda quero adicionar mais coisas, mais por aprendizado do que necessidade. Vou implementar MFA, criar um microservice de notification, configurar o RabbitMQ e implementar verificação por e-mail e TOTP.

Questão interessante é que o usuário pode escolher qual algoritmo ele irá utilizar para criptografar sua senha.

secretkey

Aqui tem um diagrama da arquitetura:

diagrama

Stacks utilizadas

  • Backend: ASP.NET Core 9.0
  • Frontend: Angular 20
  • API Gateway: KrakenD
  • Banco de dados: Postgres
  • Proxy reverso: Nginx
  • Conteinerização: Docker

Código open source

Repo: https://github.com/Moyseys/password-manager

Carregando publicação patrocinada...
2
vamoLuca

olá meu amigo projeto interessante mas eu fiquei curioso com essa parte, do conhecimendo 0 onde o servidor não sabe as senha.

Com esse projeto aprendi várias coisas valiosas relacionadas à segurança, principalmente o conceito de Zero Knowledge, que é de maneira simplória, um conceito que diz que o servidor não pode ter informação suficiente para saber o "segredo" do usuário, que nesse caso, são as senhas.

No caso como armazena elas? Não fica no banco?

1
moyseys
  • Autor
    Autor

Opa, meu amigo!
Sim, elas são armazenadas no banco, porém são criptografadas no frontend, assim o servidor só tem a informação do texto criptografado, e não tem informação suficiente para reverter.

1
vamoLuca

Como funciona isso, você poderia me falar um pouco mais?
Na minha visão o servidor deveria ser responsável por criptografar e armazenar, não?

Na minha cabeça se a forma como a criptografia está acontecendo fica no front qualquer um pode saber e caso acesse o banco fazer o reverso.

6
moyseys
  • Autor
    Autor

Opa, claro amigo! Fiz um diagrama para ajudar a visualizar.

O conceito central aqui é que cada usuário tem uma Secret Key (a chave que realmente tranca as senhas). O pulo do gato é que essa chave também fica guardada de forma criptografada (por padrão usando AES-GCM) e o "cadeado" dela é a sua Chave Mestra.

A Chave Mestra é a única coisa que não salvamos em lugar nenhum; ela vive apenas na sua cabeça.

O fluxo do diagrama funciona assim:

  • Input: Você decide salvar uma senha e o sistema pede sua Chave Mestra.
  • Desbloqueio Local: O navegador usa a Chave Mestra para descriptografar a sua Secret Key (tudo isso via Web Crypto API, sem enviar nada para o servidor).
  • Criptografia: Com a Secret Key "aberta" na memória do browser, ela criptografa a senha que você digitou.
  • Persistência: O resultado é um buffer (binário) que transformo em Base64 e envio para o back-end.

O back-end recebe apenas esse texto cifrado, sem ter a menor ideia de como abri-lo

Espero que tenha dado para entender 😁

sequenceDiagram
    autonumber
    actor User as Usuário
    participant FE as Frontend (Browser)
    participant Auth as Auth Microservice
    participant SecretSvc as Secret Microservice
    participant DB as Database (Encrypted Store)

    Note over User, FE: Entrada de Dados
    User->>FE: Digita Senha e seleciona Algoritmo
    User->>FE: Digita Master Password

    Note over FE: Processo Zero Knowledge
    FE->>FE: Deriva Chave de Criptografia (PBKDF2/Argon2 + Salt)
    FE->>FE: Criptografa o Secret com o Algoritmo escolhido
    
    Note right of FE: O segredo agora é apenas um "Ciphertext" (ilegível)

    FE->>Auth: Solicita Token de Acesso (JWT)
    Auth-->>FE: Retorna JWT

    Note over FE, SecretSvc: Envio Seguro (HTTPS)
    FE->>SecretSvc: POST /secrets { ciphertext, iv/nonce, algorithm_id }
    
    Note over SecretSvc: O servidor recebe o dado, mas não tem a Master Password <br/> para descriptografar.

    SecretSvc->>DB: Salva Ciphertext + Metadados
    DB-->>SecretSvc: OK
    SecretSvc-->>FE: 201 Created
    FE-->>User: "Senha salva com sucesso!"
2
vamoLuca

Caramba cara que explicação maravilhosa! Deu pra entender sim.
Muito obrigado pelo esclarecimento e por tirar parte do seu tempo para escrever essa explicação! Sucesso meu caro!

1
DevNegoplay

Show te bola tenho um projeto pessoal muito interessante... que faz também isso.... o meu é um gesto de ferramentas para dev... tudo que costumo usar gestão de task, gestão de senhas (não tão bom quanto o seu mas tem pin se segurança mas como é pessoal eu salvo as senhas criptografadas) ... depois compartilho aqui na comundiade..

Mas achei muito bom

1
faelpinho

Projeto interessante, parabéns!
Deixo só um pequeno conselho: prefira versões LTS do .NET (6/8/10) para ter melhor suporte pela MS e evitar que explorem falhas nas APIs quando a MS lançar a próxima LTS.

1
MrJ

Parabéns pelo projeto, @moyseys! É muito massa ver a galera aplicando conceitos de Zero Knowledge em projetos pessoais. Essa arquitetura onde o servidor é "cego" por design é o caminho certo para quem preza por segurança e soberania digital hoje em dia.

Gostei bastante do seu diagrama. O uso da Web Crypto API para garantir que a Secret Key nunca saia do browser é exatamente a abordagem que separa um projeto "comum" de um projeto focado em privacidade real.

Essa filosofia de tirar o poder do processamento (e o acesso aos dados) do servidor e trazer para o cliente é exatamente o que estou explorando no ecossistema Crom. Estamos construindo ferramentas (como gerenciadores de arquivos e notas) que seguem essa linha Local-First e Client-Side Processing.

Acho que você vai curtir bastante a proposta técnica que estamos validando por lá. Quando tiver um tempo, dá uma olhada em crom.run. Seria massa trocar uma ideia sobre como você planeja escalar esses microserviços mantendo o Zero Knowledge!

Sucesso no desenvolvimento!

0