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

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

0