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!"